Introduction to: SSL Certificates

Introduction

As the Internet matured over the years, the importance of securing the transmission of sensitive data became increasingly evident. One solution for securing this transmission is the utilization of an SSL (Secure Sockets Layer) certificate and inherently the (Transport Layer Security) TLS/SSL protocols.

An SSL certificate and its protocols (TLS/SSL) provide a means for securing several different communication types. Most commonly Internet users are familiar with its implementation on e-commerce websites whereas it serves as a means to secure private customer data transmission between the web server and client.

Terminology

First, let’s start by building an understanding of SSL certificate vocabulary. Once we have a basic understanding of the terminology used, we can better understand the technology as a whole.

SSL Certificate

An SSL certificate is an electronic document that is digitally signed and issued by a certificate authority. Each certificate stores the “subject” or identity of the certificate owner. Additionally, all certificates have another component known as a cryptographic key pair. A cryptographic key pair’s composition is made up of two keys: a public and private key. Only the public key is stored in the certificate.


Public Key

A public key is a cryptographic key that makes up the first part of a key pair. It is publicly visible to all parties as the name would imply. Its purpose is to encrypt data or verify a digital signature.


Private Key

A private key is a cryptographic key that should always be kept secret from untrusted parties, hence why it’s named “private”. Its purpose is to decrypt data or digitally sign it. A private key can only decrypt and sign data that used its corresponding public key.


Symmetric Session Key

A symmetric session key is a cryptographic key that is randomly generated from the public and private keys. Its purpose is to provide a means for speedier encryption and decryption of data in comparison to public and private key exchange.

After the initial SSL handshake has taken place, a symmetric session key is used in place of exchanging the public and private keys each time data transmission occurs. Its usage being limited to a single session between the client and server. Once a new session between the client and server occurs, a new symmetric key is generated.


CSR

In order to obtain an SSL certificate from a certificate authority, you must provide a certificate signing request (CSR). A CSR is the component that fulfills the information requirements necessary to obtain an SSL certificate.

Requirements for generating a CSR entail the following:

  • Organization name
  • Organizational division
  • Common name (domain)
  • Administrator email address
  • City
  • State/Province
  • Country

  • It is generated on the server that the SSL certificate will be installed on. Additionally, the public key associated with your private key is included in it as well.


    Certificate Authorities

    SSL certificates are typically issued by public certificate authorities, or CAs, which are third parties deemed as trusted by the majority. Public certificate authorities are subject to stringent security testing in order to be considered trustworthy by the software that utilizes them.

    Anyone can become a certificate authority within the scope of your network(s). However, to be considered a trusted authority outside of your network(s), you would have to abide by each software’s rules for doing so.


    Intermediate Certificate Authority Certificate

    The role of an intermediate CA certificate is to act as a stand-in for the root certificate. It provides further proof of the integrity of an SSL certificate since it is signed by the root certificate. Essentially, they assist in completing the “chain of trust” without having to expose the root certificate itself.


    Root Certificate

    Root certificates are considered the top most certificate in a certificate hierarchy tree. All SSL certificates are signed by a root certificate, which in turn allows them to inherit the trust of the root certificate that originally signed it. Any software that is capable of utilizing an SSL certificate, such as a browser, has a list of root certificates that are automatically designated as trusted.


    Trusted Root Certificate Authorities

    A trusted root certificate authority is any certificate authority designated by the user or software as automatically trusted. This means that any certificate issued/signed by one of these authorities will not need to be manually approved.

    The list of trusted root certificate authorities varies for each software. An example list for the Firefox web browser can be found at the following link:

    https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/included/

    Most certificates that are supported by one piece of software are typically recognized as trusted by the majority of software.

    Putting It All Together:
    The Handshake Process

    Step SSL Handshake Process
    1 A client (browser, mail client, etc.) connects to a server that utilizes an SSL certificate and makes a request that the server identify itself.
    2 The server responds with its corresponding SSL certificate for the requested domain.
    3 The client then performs several checks to confirm the validity of the certificate that it just received. This entails checking it against its list of trusted root certificates, its status (expired, revoked, or valid), and whether or not it matches the common name for the domain requested.
    4 As long as the client trusts the integrity of the certificate, it sends back a symmetric session key back to the client. This starts an encrypted session that serves as the last step in the handshake process. All further data transmission between the server and client is now being encrypted using this session key.


    NOTE:

    All of the above steps must be successful in order for the handshake to be complete.

    Types of SSL Certificates and Requirements

    Standard Certificates

    Only one domain is securable with a standard SSL certificate. They are the cheapest solution available in the SSL certificate market. Differences in pricing for these type of certificates vary from the certificate authority that issues them. The more recognizable and trusted the certificate authority; the more expensive the certificate. Essentially, you’re paying more money for a well-known brand.


    Unified Communications Certificates

    UCCs were originally introduced for Microsoft Exchange configurations, but their usage is not limited to it. It differs from standard certificates by its use of the subject alternative name (SAN) in the certificate. A SAN enables you to secure a list of domains within a single certificate. Additionally, UCC certificates allow you to secure three domains by default, and supplementary domains can be added at a cost per domain up to one hundred securable domains.

    A potential downside to their usage is that the site seal and certificate issuance information will only list the primary domain in the certificate information. Furthermore, it lists the secondary domains in the certificate. If you don’t want your domains to appear related to one another, then it is not advised to use this type of certificate. Another drawback to this type of certificate is that if you decide you want to add another domain, then the certificate will have to be re-issued to cover it.


    Wildcard Certificates

    A wildcard SSL certificate allows you to secure any number of single level subdomains (meaning that it cannot be a subdomain of a subdomain). These certificates are more expensive than standard certificates due to the infinite amount of subdomains that you can have secured by it. If you have more than a few subdomains that you would like to have secured by SSL, it would be wise to purchase a wildcard certificate as opposed to separate certificates for each subdomain.


    Extended Validation Certificates

    Extended validation certificates or EV certificates, are the most expensive type of certificate that you can purchase. As with standard certificates, only one domain can be secured with this type of certificate. Their purpose is to provide the highest level of confidence to your users as well as provide you with the best warranty from the issuer.

    If you intend on purchasing an EV certificate, be aware that several additional requirements are necessary in order to obtain one. It should also be noted that an EV certificate typically takes longer to be issued in comparison to other forms of SSL certificates, which is due to the manual verification process required.

    Additional requirements for EV certificates include the following:

  • Proof of business registration
  • Proof of operation at the physical address
  • An establishment of exclusive control over the domain
  • Confirmation that the requestee has authorization on behalf of the organization

  • Due to the amount of verification involved in obtaining an EV SSL certificate, it is not possible to receive a wildcard EV certificate. Once you have obtained an EV SSL certificate and configured it for your domain; it will display similarly to other certificates in your browser, but with an additional green bar around it.

    Additional information can be found at the Certificate Authority forum here:

    https://cabforum.org/about-ev-ssl/


    Free Certificates: StartSSL

    StartSSL is a Certificate Authority that provides free certificates with minimal requirements. If you’re looking for a free solution for an SSL certificate, then you should check out StartSSL:

    https://www.startssl.com/?app=1


    Dedicated IP Requirement and SNI

    Normally, a dedicated IP address is required in order to install an SSL certificate on a domain. However, with the implementation of Server Name Identification (SNI) into the TLS protocol, this is no longer required.

    SNI is an extension of TLS, which allows you to set up more than one SSL certificate per IP. It works by sending the name of the virtual domain as part of the normal TLS handshake. In turn, this allows the server to choose the certificate associated with the domain, and therefore it can send back the corresponding certificate. Its only disadvantage being that incompatible (older) browsers will return a certificate warning.

    Conclusion

    Now that you have a better understanding of SSL certificates, you can use this knowledge to implement them and secure any communication type that supports them. For instance, you could secure your mail servers with a wildcard or UCC certificate.

    Written by
    on March 27, 2015

    Facebook Twitter Google+ LinkedIn Addthis