How does all this work? HTTPS, SSL, certificates, CA, public and private keys, CSRs?

http://wpengine.com/support/how-does-all-this-work-https-ssl-certificates-ca-public-and-private-keys-csrs/

HTTPS, SSL, certificates, and all the other bits and pieces of browser security is complicated, and it’s hard to get a simple, clear explanation of what it means and what to do. Hopefully this will help.

CAVEAT

This description intentionally omits various details and exceptions. The purpose is to give a non-technical user a clear picture of how all this stuff works. Extra complexity would just cloud this clarity. Use references like Wikipedia and security books for completely precise information.

HTTPS AND SSL

SSL stands for Secure Socket Layer, and it’s a protocol that does two things:

• Encrypts your data, which means no hacker can see what your browser sends to the server nor what the server sends to the browser.
• Authenticates your website, which means it tells your browser “This website really is who it claims to be.” For example, that when you type your username and password into your PayPal account, that the website really is PayPal, and not a hacker posing as PayPal.

HTTPS just means “HTTP with SSL.” Just as “http://” means “this is a website,” seeing “https://” means “this is a website, and it’s using SSL to encrypt data and authenticate the website.

So when you want a “secure website,” i.e. a website with https, you’re saying you want us to support the SSL protocol. It turns out the encryption part of that protocol we can handle completely automatically for you, but the authentication part is a lot trickier. So the rest of this will be about authentication.

CERTIFICATES

A Certificate is a document that your website shows a browser to proclaim its identity. It “certifies” that the website is who it says it is.

It includes web-stuff like your domain name (e.g. “paypal.com”) and also identification-stuff like your company’s name, address, phone number, and so forth. Some certificates provide more information than others, but this is the general idea.

Simple enough, but the trouble is it’s not authentication. Because: Although PayPal provides a certificate identifying themselves as PayPal, a hacker could just as easily provide that same certificate to the web browser! How does the browser know that this certificate is to be trusted?

CA stands for “Certificate Authority,” and it’s a company who will verify for the browser that a particular website’s certificate can in fact be trusted. All browsers come pre-loaded with special security files listing dozens of CAs whose opinion it will trust.

So it’s not enough that your website provides a certificate, it needs to be a certificate that has been certified by a CA. This is called a Signed Certificate, because the CA has “signed their name” to your certificate so that the browser will trust it.

To get a signed certificate you first need to select a CA. There are literally dozens of CAs; some examples you might have heard of are GoDaddy, Verisign, but if you search on Google you’ll find a zillion of them. Prices range from $50 to $5000 depending on lots of factors. You’ll need to consult with your CA or a technical consultant to decide what’s right for you since there’s lots of details and trade-offs.

Next you’ll need to generate other documents which you provide to the CA in order for them to process and issue your precious signed certificate. I know, like Alice and Wonderland you’re going further down the rabbit hole…

PUBLIC AND PRIVATE KEYS

A Private Key is a secret password that your website keeps and which you never ever ever let anyone have access to except your hosting company and your CA. Unlike your email password, this password is really long, typically 1024 characters or more. That’s a good thing — a human being never needs to read it, only machines, so it’s good to have something so massive that it really is literally impossible for anyone to guess it.

The private key is a required component of SSL because it’s part of how it does the encryption part of its job. It’s also a required component of the certificate and the CA’s approval, because what you’re really saying is this:

“This secret, private key XYZ is something that only me, the real website, knows. So I want you, the CA, to verify to him, the browser, that this certificate (my identity) is one and the same with this private key. So then when I use that private key to send encrypted stuff to the browser, the browser will be certain I’m who I say I am, and we’re in business.”

But wait — if you use the private key to encrypt data, doesn’t that mean the browser needs that same private key to decrypt the data? And then the private key isn’t a secret anymore! Don’t worry, that’s not how it works. It’s like this:

When your security tool creates one of these special private keys it also creates a corresponding, matching Public Key. This is a different password, but also really long, like 1024 characters. The public and private keys are a pair with the following very useful feature:

Data encrypted with the private key can only be decrypted with the public key. (And vice versa.)

So here’s how this all gets put together:

Your website keeps the private key secret, and encrypts everything with that key. The public key is placed inside that certificate as yet another part of your website’s identity, just like your domain name and phone number. When the CA certifies your certificate, it’s telling the browser, “Yes this is the real-life identity of this website, and furthermore that’s the public key of this website, so you can trust anything that you can decrypt with that public key.”

Since only the private key can encrypt stuff for that particular public key, only you, the real website could be talking to that browser, providing that certificate, and that’s how the browser knows you’re actually you.

It’s also why you need to keep that private key secret. It’s also why you will need to give that private key to us, your hosting provider, because we’ll need it to encrypt data coming from your website.

Now there’s only one more thing you’ll need to get this friggin’ certificate certified by the friggin’ CA:

CSR stands for Certificate Signing Request, and it’s the official document you give to a CA asking them to “sign” your certificate, thus finally getting you that “signed certificate.”

The CSR essentially just combined all the stuff we just discussed — the public key, the certificate you want signed, etc — in a standard format. There are security tools which generate CSRs depending on what fields you need to fill out and using your keys.

It’s a common mistake to think the CSR is the same thing as a signed certificate, but as you can see that’s not at all the case. The CSR is literally a request, not a signed certificate. Only a CA can provide you with a signed certificate.

GETTING IT ALL LIVE AND WORKING

To host your HTTPS-powered website, we’ll need two things:

• Your private key (so we can encrypt data)
• Your signed certificate (so we can provide that to browsers)

We don’t need your public key, CSR, or any other things you might have generated along the way.

You can purchase and configure an SSL Certificate in the User Portal by following this guide.Please note, we only offer SSL on our Professional and above Plans.

CHAINED CERTIFICATES (NEEDED ONLY SOMETIMES)

About 10% of the time your CA will require you to use something called a Chained Certificate. If that’s not the case for you, you can skip this section.

Here’s why this happens: Remember the web browser has a list of CAs which the web browser trusts. Now suppose you used a CA which was not in that list. The browser won’t accept your certificate because, although it’s signed, it’s signed by a CA which in turn the browser has no reason to trust! This unknown CA could just as easily be a hacker.

To get around this, your CA will provide you with another certificate that says “I’m a CA you should trust, and look, I got this other CA to certify that I’m a trustable CA, and you do already trust that CA.”

In short, your CA passes the buck to a trusted CA, therefore creating a “trust chain.” The browser trusts your website because your CA says so, and it trusts your CA because another CA says so, etc., until we get to a CA the browser trusts implicitly because it’s in that “official list of trusted CAs.”

If this is the case for you, that’s fine! We just need you to send us that additional certificate so we can provide the complete chain to the browser. Your CA will be able to give you that document.

DEDICATED IP’s

You can only have a dedicated IP provisioned for your site if you have an SSL certificate. You have to have the SSL certificate first before we make the request to get the dedicated IP for your site.