Everything You Wanted to Know about SSL Certificates

SSL certificates are pervasively used on the Internet for securing all the data sent between servers, devices, clouds, phones, computers, etc.  SSL certificates are intrinsic in the encryption of communications using  “SSL and TLS” (how do these work?  What is the difference?) — you can’t have secure communications without them!

In this article, we answer many common and not-so-common questions about SSL certificates.

What is an SSL Certificate?

An SSL Certificate is a set of files that enable the server to provide “asymmetric encryption” with a connecting computer, device, or other server (known as the “client”).  These files include:

• Signing Request. A file ending in “.csr” which is presented to a 3rd party and which is used by that 3rd party to generate the “public key”.
• Private Key: A file ending in “.key” which is installed on the server and which is kept secret and secure.
• Public Key: A file ending in “.crt” which is installed on the server, but which is given freely to any connecting device (client). Anyone can have a copy of this file without interfering with the security of the system.
• Intermediate Certificates.  Additional files provided by the 3rd party that generated and signed your “public key”.  These are public files and need to be installed on the server so that connecting devices can properly verify your site’s identity.  If you forget to install this, your users connecting to your web site may get SSL warnings and be wary of trusting your site.

What is IN an SSL Certificate?

The “public key” file for your SSL certificate contains several important pieces of information:

• Information for encrypting data
• Information about your domain name and possibly also your organization
• A date range where the certificate is valid (e.g. when it expires)
• Information about what organization (if any) “signed” your public key.

The “private key” file for your SSL certificate contains only information for encrypting data — it does not expire or have any details regarding your organization or domain name.

The “signing request” contains all of the same information as the “public key” except for information about who has signed it.

What is a “self-signed” certificate and when would you want one?

A “self-signed” certificate is one in which you yourself have “signed” the certificate (e.g. when you or your hosting company created it).  Self-signed certificates are free and anyone can make them with any information in them regarding organization and domain name.  E.g. you could make one yourself that is for the computers of the NSA (National Security Agency).

However, anyone who connects to a server using a self-signed certificate will immediately get a significant warning message in their connecting program (e.g. web browser, email program, etc.) that the server it is connecting to is not trusted and that you should proceed with extreme caution.

Self-signed certificates are typically used only for:

• Services hosted inside of your own corporate network where you control who accesses the server and the server itself.  E.g. your staff may trust your own certificates in that case.
• Public services where the users care only about the fact that the data is encrypted and which do not care who is on the other end of the data stream (this is rare).

Everyone else wants a “signed” certificate.  E.g. they pay some company like Verisign, or Thawte, or even GoDaddy to “sign” their certificate so that all these trust warnings just “go away”.

What does certificate signing do and why does it cost money?

A company that signs your certificate must first verify your right to the certificate in question.  Then, they add stuff to the certificate that allows others to see that they indeed have verified your ownership of and right to use this certificate.

What does that mean?

• They check that the domain name in the certificate is actually owned by you and the people in charge of the domain approve the creation of this SSL.
• If there is information about your organization (e.g. your company name) in the certificate, then this must also be verified.  People in charge of this company must approve the certificate.

So

• You can’t get a certificate signed for domains that you do not have control over
• You can’t get an organization’s name in a certificate unless you have permission for that
• You’ll never get that “NSA” self-signed certificate to be signed by a trusted third party (unless you happen to work for the NSA, that is).

The expense of the certificate covers

• The time and effort needed to verify
• The more things that must be verified and the better job a third party does, the higher the cost and the higher the trust of the result

Be careful of certificates signed by very cheap SSL providers like GoDaddy.

What is an EV SSL Certificate and why does it turn the browser green?

An “EV” certificate is an “Extended Validation” certificate.  For these, the 3rd party signer goes through a significant effort to verify the company and domain in the certificate.   Visiting a site that has an EV certificate generates a high degree of trust that the site is really the one you are trying to connect to (and not some fraudster) .  As a result, most web browsers identify this with a green address bar.

See Extended Validation (EV) SSL Certificates for more information.

Why do I need a dedicated IP address for my SSL Certificate?

The way that SSL (and TLS) works, the establishment of a secured communication channel comes first, before any information is sent between your computer and the server.  When establishing this secure channel, your computer connects to the Internet address (IP Address) of the server and “does the encryption stuff”.  Telling the server what domain name you are trying to get to is not part of this process.

E.g. if you are trying to get to https://luxsci.com, your web browser would connect to LuxSci’s servers on IP address “66.216.79.80” and do the encryption things … without ever telling the server that it is trying to connect to “luxsci.com” (that would come later, after the encrypted connection is all set).

So, the server cannot choose what SSL certificate to present to you based on what site you are trying to connect to…. it has to give the same certificate every time for every connection … the certificate configured for the IP address “66.216.79.80”.

Thus, every SSL certificate needs to reside on a different IP address.  When a web browser connects to your dedicated IP address to access your web site securely, it will absolutely be given your SSL certificate.  If the wrong certificate was presented, then the web browser would complain that the certificate received doesn’t match the domain name it is trying to connect to.

The same process applies to connecting to email servers over SSL and any other service over SSL.

What about “wild card” SSL certificates?

A wild card certificate covers a wide range of domains.  E.g., the certificate for “*.luxsci.com” covers all direct subdomains of “luxsci.com”.  For example, it covers “smtp-5.luxsci.com” and “webmail.luxsci.com” and “www.luxsci.com”.

However, such a wild card certificate does not cover plain old “luxsci.com”.  It also does not cover lower-level subdomains like “a.b.luxsci.com”.

The benefits of a wild card certificate are:

• You only need to buy 1 SSL Certificate to cover a large number of similar domains
• You only need 1 IP address for that certificate

While wild card certificates are more expensive, in general, they are a good value if you have many domains to protect.

Can I use the same SSL Certificate for different things like email and web sites?

That depends on if those services are located on the same server (IP Address).  If your domain was “secure.com” and you wanted to use this for both secure email (e.g. POP and IMAP) and your web site, then these things would generally need to be served on the same server … so that the IP address of your web site and your email is the same and thus you can configure the address of “secure.com” with that address.

If your mail and web sites were on different servers or IP addresses, then you would not be able to setup your domain “secure.com” so that it goes to one place for web and another place for email (without special hardware firewalls and other types of traffic redirecting rules that are not generally in place in common configurations).

At LuxSci, customers of our shared services have their email on one server, their web sites on another server, and their WebMail on a third set of servers — this is for security and performance reasons.  So, if they wanted to secure all three things with their own branded domain name and SSL, they would need up to 3 certificates (or 1 wild card certificate) … one for each server.  Customers with dedicated servers can have all of these services located on their single machine and can use 1 regular certificate for all of them.

LuxSci provides SSL for your for secure email and WebMail.  If you want to private label that, you might want to add your own secure domain name.  If you want to secure your web site, you might want SSL for that as well.

Does adding an SSL certificate to my web site make it secure?

Merely adding an SSL certificate to a site does not make the site secure.  Once you have an SSL Certificate for your site you need to ensure that web pages that require security are only accessed over SSL (e.g. you need to link to them with https:// and not http:// links).

You may also want to construct your site so that secure pages cannot be accessed via insecure links (e.g. http://).   This is easily done at LuxSci as we can provide a separate area of your web site for files only accessible over SSL.

Read more about how to be sure that your site is secure.

Are web pages that end in “.shtml” secured with SSL?

It is a common misconception that “.shtml” web pages are “Secure HTML”.  This is not so.  The “S” stands for “Server-Parsed” and is related to server-side includes.  This has no bearing on security of encryption and does not mean that the page is secure.

The page is only secure if the URL in the address bar starts with “https://” and your “lock icon” in your browser is closed (locked).  Also look to be sure that the lock icon does not have a warning sign or “X” on it and that the address bar is not “red” … as these can indicate that there is either some problem with your SSL certificate (like it expired) or that there are items (like images or JavaScript) in your web page that are being loaded without SSL and thus defeating some of the reasons for having the page secured in the first place.  Contact your web developer if you have questions about such issues … they may be “OK” in some cases and not in others.

Read more:

• What’s the latest with SSL/TLS Certificates?