Home/ Questions/Q 8251965
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-08T00:24:36+00:00

I’ve got a certificate for a domain I own, on StartSSL. So this gives

  • 0

I’ve got a certificate for a domain I own, on StartSSL. So this gives me:

  • an intermediate CA certificate
  • StartCom Root CA certificate
  • private key

In order to receive these, I sent StartSSL this:

  • proof I own mydomain.com (by email code verification)
  • a CSR I made from a private key I already have

It seems like what I need to do is to put this key and this certificate chain onto my server so that OpenSSL on the server will be able to use them to reassure the web browser.

But which private key is which? I have the private key I generated the CSR from and the private key I got from the CA.

What I’m also not 100% clear on is what is being assured here. The browser looks at the certificate, which tells the browser that it should have connected to mydomain.com.

All StartCom knows is that I have shown them that I own mydomain.com and I am the only person who has this private key. This is what is passed on and so now the browser connecting from Yugoslavia also has this information now.

So my web server is on a cheap home connection with a dynamic IP. I set DNS at my domain registrar to direct mydomain.com to myname.dynDNSProvider.com using a CNAME and my dynamic DNS service has myname.dynDNSProvider.com redirected to my dynamic WAN IP on my router at home.

When the IP changes, requests get directed to somebody else or nobody at all. Everything’s okay because an attacker cannot set up a server with a valid certificate that reports mydomain.com. And I must also trust my DNS services. Once I update the IP everything works again.

So is this how it works? Is the redirect path from my domain to my actual IP not relevant for the purposes of SSL authentication? Could my DNS service providers, if they so choose, perform attacks more effectively than an outsider?

I’m basically just trying to set up a secure connection to my home server on the cheap, and in order to accomplish it on the cheap I’m totally fine with whatever short downtime the dynamic DNS will cause. The particular problem I’m trying to solve here is to get browsers not to say “invalid certificate!!!” when they see my self-signed SSL cert coming from my server.
I’m having some difficulty finding good resources to learn about how this stuff works.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    But which private key is which? I have the private key I generated the
    CSR from and the private key I got from the CA.

    You got a public key from the CA. What that public key is, is the one which was part of your CSR, plus an attestation from CACert which means basically “we validated this”. I’m simplifying, but that’s the gist of it. You use the private key you have along with the public-key-bearing certificate you got from them.

    As for the DNS bit, what the certificate says is “I’m okay for example.com“. If the web browser is attempting to connect to example.com, and the server has some certificate which is valid for example.com and was signed by a certificate in the browser’s trust store (CACert is in both the Mozilla and Microsoft stores), you’re set. Which IP address the connection results in doesn’t matter unless there’s an IP address in the certificate (and that’s not standard practice; CACert issues certificates with subjectAltNames set to DNS names only).

    Could my DNS service providers, if they so choose,

    Since you trailed off your question, it’s a little hard to answer. But your “DNS providers” (I assume you mean the dyndns service) could do three things: send the traffic to their own servers, send it to nowhere, or send it to you after intercepting it. Let’s address there attacks individually.

    First, sending the traffic to their own servers. If they can’t get a valid certificate for your domain, and you require SSL for all connections (no user ever issues a non-SSL request), then this does them no good. Their forged certificates will show up as invalid and the game is up.

    Second, sending the traffic to nowhere. Denial of service. Not interesting in this context.

    Third, attempting a man-in-the-middle attack. The issue here is that traffic the client sends is only readable by someone with your private key – which they don’t have. So, unless they can get a valid certificate for your domain and present that instead of the one you have, they can be in the middle and still be unable to read the traffic – so this attack really boils down to the first one. You’re pretty safe.

    • 0