SSL Certificate Management: Practical Guide

One of the things faced by many network engineers is the maintenance and update of SSL certificates. For the author, SSL certificates are mainly used for VPN deployment, but there are also many network devices that need certificates to encrypt client-to-server communication. Every time I claim that I need a certificate, everyone will become speechless, and the certificate may be a bit scary for most people. After all, many existing resources that use the public key encryption technology are either in the "confidential" state or use the principle that is too abstract for pragmatism. This article aims to solve this problem and introduce the basic knowledge of SSL certificates and some common practical examples.

Basic SSL Certificate knowledge

Common certificates used by Web servers and related devices are mainly composed of three parts:

• The private key of the subject. This includes unique identifiable information about the subject, which is usually a Web server, but may also be a personal user. The private key is usually generated on the host itself and theoretically never leaves the key storage zone of the operating system. A certificate signature request is also generated when the private key is generated.

• CA Public Key: a ca is a trusted server. Currently, many Certificate Authorities provide certificate services, such as DigiCert or VeriSign. In addition, this may be a private CA, such as a CA in the Microsoft Windows Server operating system. If a copy of its public key exists in the certificate library connecting to the client (whether a Web browser or the operating system itself), the CA is considered credible.

• The main public key. When CA signs the information in the CSR file generated from the private key, a public key is generated. This public key is designed to be transparently transmitted and contains a signature to verify authenticity and usage (such as server or client authentication.

When our principal server receives a connection request, it will present its signed Public Key so that the client can verify its identity. If the client trusts our public key, it will consider encryption, and the public key will be used to encrypt the client's session key. This session key can only be decrypted by our private key and can be connected to other secure sockets.

Wildcard Certificate

When creating a private key, the public name (CN) will be specified. In most cases, this is a fully qualified domain name (FQDN) for the host, such as www.foo.com. If many servers need protection, a more economical and practical approach is to create a wildcard certificate (wildcard certificate) for all data in a given domain ). This is also useful when you need multiple virtual identities (such as www.foo.com, mail.foo.com, and ssl.foo.com) on a logical host (such as a server Load balancer. When a key is generated, instead of using a single FQDN for a specific host, the host is replaced by a wildcard, for example, *. com. Therefore, this certificate is valid for everything in the DNS domain, but does not include all subdomains. Most modern client browsers support wildcards, but you may encounter a few exceptions, such as embedded browsers or earlier versions of IE browsers.

Host backup name

A relatively abstract but useful feature is the entity backup name (SAN ). If you need a wildcard certificate and a connection from a traditional Client, some CAS use valid backup names to sign the subject's public key. Even the old client SSL deployment supports this function, which allows the subject Public Key domain to replace the name as follows:

• CN = * .foo.com

• SAN = www.foo.com, mail.foo.com, ssl.foo.com

Even if the client does not understand the wildcard in the general name of the subject, it will still match a backup name and accept the validity of the certificate.

Intermediate CA

The vast majority of client certificates are not issued by the root CA, but by the Intermediate CA. Essentially, the root CA signs the public key of the intermediate CA and allows it to sign the certificate in place of it. This type of Authorization signature may occur several times, and the certificate you obtained may experience several layers of certificate organizations. In the following example, the subject's certificate www. amazon. co. uk is signed by the VeriSign Class 3 Secure Server CA-G2, which is signed by the VeriSign root certificate.

 

Common intermediate certificates are embedded in the client certificate storage area, but many valid intermediate certificates from Internet service providers or domain name registrars do not. The intermediate Certificate needs to be connected to the Web server, so that the client can follow the certificate chain until a certificate signed by a trusted CA is found. Based on my experience, this explains why the Certificate Trust error still occurs when a user connects to a website with a paid certificate. The Certificate Authority provides the binding between the root and the subordinate public key. You need to import it to the Web server for configuration. Many CAS provide online tools to check whether intermediate certificates are correctly installed. When importing your signed public key, you need to check whether the intermediate Certificate needs to be paid attention to avoid support for calls.

Certificate Management

OpenSSL encryption toolkit is a "secret weapon" for engineers to manage certificates ". These binary files are included in most * nix versions and can also be used in Windows. This powerful tool is worth learning, so we do not need to remember the nuances of Local Certificate Management on multiple platforms. The lite version can meet most daily needs.

Microsoft. PFX file binding key

PFX files are mainly used in Microsoft environments. Generally, keys are generated in Windows and automatically signed by the domain integration CA. This is useful because the private key, the signed public key, and the CA Public Key are bundled into a single file. This key can be encrypted with a password. When you transmit a certificate over a public network, this can provide some protection. By using OpenSSL, a single component can be exported and converted. In addition, these files do not contain human readable parts.

PEM and DER encoding

Common x.509v3 certificates are encoded in two formats: PEM or DER, and are generally assigned a. CRT or. CER file extension. These file extensions do not let you know their formats, because they are used interchangeably, but their content can give you some tips. The PEM file is Base-64 ASCII encoded with the prefix "---- begin certificate ----" and the suffix "---- end certificate ----". DER files are binary encoded and not readable.

When exporting a certificate from Windows, you can select three formats: DER, PEM, and P12. However, it is not clear which one is used.

Many network devices require certificates and keys to be imported in PEM format, but the Windows MMC Certificate Management Unit only allows private keys to be exported in P12 format. This is only half the success, because you also need to extract the public key of the signature body.

Extract the public key from the PEX file in PEM format

The exported Public Key clearly displays the name of the server that issued the public key and the name of the root-level CA that signed the public key. You must check whether you are using the correct certificate (for example, a certificate signed by a commercial CA rather than an internal domain CA ).

To reverse this process and combine the private key, public key, and CA certificate into a single file, you need to use the following command:

C: \ cert> openssl pkcs12-export-out NewPfx. pfx-inkey justPrivateKey. key-in justPublicKey. crt-certfile CACert. crt

Load "screen" to random state-complete

Enter the export password: <set a new password>

Verify the exported password: <repeat the new password>

Conversion 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 it back:

C: \ cert> openssl x509-inform der-in justPublicKey. der-out justPublicKey. pem

It is worth noting that this process usually removes the plain text extension attribute and only leaves the original CERTIFICATE between the "---- begin certificate ----" and "---- end certificate ----" buffers.

Solve Certificate Management Problems

Inevitably, you may encounter something that cannot run normally. In this case, the first step is to use the local OpenSSL tool to check whether the format of your key and certificate is correct.

Check the private key file:

C: \ cert> openssl rsa-in justPrivateKey. key-check

Check the CSR:

The above example clearly shows the entire certificate subject. The two key components here are "O =" (Organization enterprise) and "CN =" (Canonical Name, Canonical Name ). The enterprise field must be exactly the same as your registry name. For example, if your Company registration name is "Foo Company Plc (UK)", it will be rejected if you submit "Foo Company UK. In addition, the domain name specified in the certificate must be registered by you or an authorized third party.

Verification Certificate (PEM or DER format ):

C: \ cert> openssl x509-in CACert. crt-text-noout

In the following example, the author analyzes the VeriSign CA public key, which can collect a lot of valid information:

• Valid date of the Certificate. All certificates have a validity window before they need to be signed again. The validity period of a Web server certificate is generally less than three years, while that of a CA certificate is usually 10 years or more. An inexperienced network administrator may create a domain root-level CA by using a one-year certificate. In this case, the CA root certificate will soon expire and expire, even if the signed certificate has a longer validity period.

• Key strength. The RSA key has a given strength: the more digits it uses, the harder it is to guess. Many public CAS now only sign 2048-bit keys, but 1024-bit or even 512-bit keys are used in internal applications.

• Key usage. Unless you are doing something fuzzy, at least this should include Transport Layer Security Web Server Authentication and TLS Web client authentication.

• Certificate Revocation List (CRL) and Online Certificate Status Protocol (OCSP) distribution point. Some clients perform more real-time checks on certificates to ensure that they are not revoked by using static CRL or dynamic OSCP protocol. Public CAS provide public access to these services, but private CAs may not correctly configure these services or allow remote client access.

• Subject backup name. As discussed earlier, SAN allows certificates to have several different identity certificates. All configured SAN may explain why the subject name is obviously different and the certificate can also pass verification.