Original page is here written by Glen Kemp
One of the chores many network engineers face is the maintenance and renewal of SSL certificates. In my case this is mostly for VPN deployments, but many network appliances require a certificate for encrypted client-to-server communication. Given that I’m often met with deafening silence when I drop the bombshell that I’m going to need a cert, I’m guessing that this whole business is a bit of a black art to most. It’s perhaps no surprise when a lot of the existing resources on scary-sounding public key cryptography either assume elite ninja status or use principles that are too abstract from the practicalities. The goal here is to remedy that confusion somewhat, explain the basics and include some common real-world examples.
The basics of SSL certificates
The common garden-variety certificates used by Web servers and associated devices consist of three parts:
- The subject private key. This contains uniquely identifiable information about the subject; this is usually a Web server, but could be an individual named user. The key is usually generated on the host itself and theoretically never leaves the privacy of the OS Key Store. At the time of generation, a certificate signing request (CSR) is also created.
- The CA public key. The certificate authority (CA) is a server which is trusted by all parties. This can be one of any number of services, such as DigiCert or VeriSign. Additionally, this may be a private CA, like the one available in the Microsoft Windows Server operating system. The CA is considered trusted if there is a copy of its public key in the certificate store of the connecting client; either the Web browser or the OS itself.
- The subject public key. The public key is created when the CA signs the information held in the CSR file generated from the private key. The public key is designed to be transferred in the clear and contains a signature that verifies the authenticity and validates applicable use such as server or client authentication.
When our subject server receives a connection request, it presents its signed public key so that the client may verify its identity. If the client trusts our public key, the ciphers are negotiated and the public key is used to encrypt the client session key. This session key can only be decrypted by our private key, and the rest of the secure socket connection can be completed.
Wild card certificates
At the creation of the private key, the common name (CN) is specified; in most cases this is the fully qualified domain name (FQDN) of the host, such as www.foo.com. If many servers require protection, it is often more economical and practical to create a wildcard certificate for all hosts on a given domain. This is also very helpful when you need several virtual identities such as “www.foo.com,” “mail.foo.com” and “ssl.foo.com” on a logical host, such as a load balancer. At key generation, instead of using a single FQDN for a specific host, the host portion is replaced with a wild card, such as “*.com.” As a result, the certificate is valid for anything on the DNS domain, but not usually any subdomains. Most modern client browsers support wild cards, but you may run into a few exceptions with embedded browsers or early versions of Internet Explorer.
Subject Alternate Name
A relatively obscure but useful feature is Subject Alternate Name (SAN). If you require the features of a wild card certificate but are expecting connections from legacy clients, some CAs will sign the subject public key with a number of valid alternate names. Even ancient client SSL implementations support this feature, which allows the subject public key fields as such:
- CN = *.foo.com
- SAN = www.foo.com, mail.foo.com, ssl.foo.com
Even if the client doesn’t understand the wild card in the subject common name, it should still match one of the alternative names and accept the certificate as valid.
Intermediate CA
The vast majority of client certificates are not issued by a root-level CA but by anintermediate certificate issuing CA. Essentially, the root-level CA signs the public key of an intermediate CA, permitting it to sign certificates on its behalf. This can happen several times, and you could end up with a chain of certificates several layers deep. In the below example, the subject’s certificate, “www.amazon.co.uk,” has been signed by the VeriSign Class 3 Secure Server CA – G2, which is in turn signed by the VeriSign root certificate.
The common intermediary certificates are embedded in client certificate stores, but many legitimate intermediaries from Internet service providers or domain registrars are not. The intermediary certificates need to be attached to the Web server so that the client can follow the chain until it finds a certificate signed by a trusted CA. In my experience, this is the No. 1 reason why users still receive certificate trust errors when connecting to a website that has a paid-for certificate. Certificate authorities provide a bundle of root and subordinate public keys that need to be imported into the Web server configuration. Many CAs provide online tools that check whether the intermediaries have been installed correctly. When importing your signed public key, it is worth checking whether the intermediaries require attention to avoid the inevitable support call.
Certificate management
The OpenSSL cryptographic toolkit is the engineer’s Swiss army knife for certificate management. The binaries are included in most *nix distributions and are also available forWindows. This powerful utility is worth learning to prevent remembering the nuances of native certificate management on multiple platforms. The “lite” version is sufficient for most day-to-day needs.
Microsoft .PFX files bundle keys
PFX files are commonly used in Microsoft environments; typically, the key is generated within Windows and then automatically signed by a domain-integrated CA. It is useful because the private key, the signed public key and the CA public key are bundled into a single file. The key is optionally encrypted with a passphrase to provide some level of protection should you wish to transfer the certificate across a public network. Using OpenSSL, the individual components can be exported and converted. These files contain no human-readable component.
PEM and DER encoding
The common x.509v3 certificates are encoded in one of two formats, PEM or DER, and are typically given either a .CRT or .CER file extension. The file extensions themselves do not tell you much about their format as they are used interchangeably, but the contents can give you a pointer.PEM files are Base-64 ASCII-encoded and are prefixed with “—- BEGIN CERTIFICATE —-” and suffixed with “—- END CERTIFICATE —-.” DER files are binary-encoded and are not human-readable.
When exporting a certificate from Windows, you are offered three common formats: DER, PEM and P12, although which is which is not very clear.
Many network appliances require certificates and keys to be imported in PEM format, but the Windows MMC certificate management snap-in will only permit private keys to be exported in P12 format.
This is only half the battle, since you will also need to extract the signed subject public key.
Extracting the Public Key in PEM format from a PFX file
The exported subject public key clearly shows the common name of the server it was issued to and the name of the root CA that signed it. It is important to check that you are manipulating the correct certificate (i.e., the one signed by a commercial CA and not an internal domain CA).
To reverse the process and combine a private key, public key and CA certificate into a single file, use the following command:
C:\cert>openssl pkcs12 -export -out NewPfx.pfx -inkey justPrivateKey.key -in justPublicKey.crt -certfile CACert.crt
Loading ‘screen’ into random state – done
Enter Export Password: <set new passphrase>
Verifying – Enter Export Password: <repeat new passphrase>
Converting between PEM and DER
Another common requirement is to convert PEM encoded files to DER encoding:
C:\cert>openssl x509 -outform der -in justPublicKey.pem -out justPublicKey.der
Then, convert them back again:
C:\cert>openssl x509 -inform der -in justPublicKey.der -out justPublicKey.pem
It is worth noting that this process will typically strip out the plain-text-extended attributes and leave you with only the raw certificate between the “—- BEGIN CERTIFICATE —-” and “—- END CERTIFICATE —-” buffers.
Troubleshooting certificate management
Inevitably, you will end up in the situation where something is not working correctly. If that’s the case, the first step is to use OpenSSL’s native tools to check that your keys and certificates are correctly formatted.
To check a private key file:
C:\cert>openssl rsa -in justPrivateKey.key –check
To check a CSR:
The above example clearly shows the entire certificate subject. The two key pieces here are the “O=” (Organization) and the “CN=” (Canonical Name). The organization field must exactly match your registered organization name. For example, if you are incorporated as “Foo Company Plc (UK),” a submission for “Foo Company UK” will be rejected. Additionally, the domain name specified in the certificate must be registered by you or an authorized third party.
To verify a certificate (PEM or DER format):
C:\cert>openssl x509 -in CACert.crt -text -noout
In the instance below, I’ve the analyzed a VeriSign CA public key, but lots of useful information can be gathered from here and checked:
- Certificate valid dates. All certificates have a window of validity before they need to be re-signed. Web server certificates are usually valid for no longer than three years, while CA certificates tend be in the region of 10 or more years. An inexperienced network administrator may create a domain root CA with a certificate valid for a single year. In this case, the CA root certificate would expire and invalidate the trust, even if the signed certificates were valid for a much longer period of time.
- Key strength. RSA keys have a given strength: The more bits are used, the more difficult it is to guess. Many public CAs today will only sign 2,048 bit keys, but it is not uncommon to find 1,024 or even 512 bit keys being used in internal applications.
- Key usages. Unless you are doing something obscure, at minimum this should includetransport layer security Web server authentication and TLS Web client authentication.
- Certificate revocation list (CRL) and online certificate status protocol (OCSP) distribution points. Some clients will do additional real-time checks of certificates to ensure they have not been revoked using either static CRL or the dynamic OSCP protocol. Public CAs make these services publically accessible, but private CAs may not have these correctly configured or accessible from remote clients.
- Subject Alternate Names. As discussed earlier, SANs allow a certificate to possess several different identities. Any configured SANs may explain why a certificate passes validation even though the apparent subject name is different.
About the author: Glen Kemp is an enterprise solutions architect for a UK-based managed services provider. He designs and deploys network and application security tools, including access control, remote access, firewalls and other “keep the bad guys out” technologies. He is an experienced professional services consultant; delivering Elephants and not hunting Unicorns. He is also a guest blogger for the Packet Pushers Podcast and a Juniper Ambassador. Follow him on Twitter @ssl_boy.