PKI and SSL – Programming by Design

(Updated July 10, 2024)

Overview
Certificates
Requesting Certificates
Cipher Suites
File Formats
Configurations
VICE

Overview

The secure exchange of information is essential to protecting vital data sent over networks. Here, we will look at the details related to PKI and SSL.

Public key infrastructure (PKI) governs the issuance of digital certificates to protect sensitive data, provide unique digital identities for users, devices, and applications, and secure end-to-end communications. PKI is the technology of digital certificates. A digital certificate is a piece of identification that proves your identity and provides certain allowances, not unlike government-issued credentials. A digital certificate allows its owner to encrypt, sign, and authenticate. PKI is the infrastructure to encrypt data, digitally sign documents, and authenticate yourself using certificates.

The Secure Sockets Layer (SSL) is one of the most common use cases of PKI used for the encrypting of payloads between endpoints when using online resources. This includes:

SSL certificates for public-facing websites and services.
Virtual private networks (VPNs).
Email security
Enterprise user authentication
Bring-your-own-device (BYOD) policies and internal mobile device management
e-commerce

Historical Note!

While SSL also refers to specific encryption models, like TLS (Transport Layer Security), the term SSL is used generically when talking about securing traffic within an application and the configuration options available.

Certificates

Part of PKI is the idea of an asymmetric two-key system. There is a private key that should never be shared and a public key issued by a certificate authority (CA) that must be shared. It works like this:

Data encrypted with the private key can be decrypted with the public key. This means any holder of the public key can decrypt your data, which is why other encryption means are also employed when pulling sensitive data from a web server.
Data encrypted with the public key can only be decrypted with the private key. This is how data sent to the endpoint remains secure.

An intermediate certificate is one issued by the certificate authority that sits between your certificate and the CA Root. The intermediate certificate is used to sign the certificate issued by the CA.

The root certificate is owned by the CA. The root is used to sign the intermediate. There is an intentional level between the root and the certificate issued by the CA to protect the root through layers of security.

With the stage set, we can now show the chain of trust and how it’s validated.

     +-------------------------+
     |       Owner's DN        |
     |   Owner's public key    |      Get certificate
     |    Issuer's (CA) DN  -----------------+
     | Issuer's (CA) Signature |             |
     +-------------------------+             |
                  ^                          v
                  |              +-------------------------+
                  |              |    Issuer's (CA) DN     |
                  +----------------  Issuer's public key   |      Get certificate
            Verify Signature     |  Issuer's (Root CA) DN ---------------+
                                 | Issuer's (Root CA) Sig. |             |
                                 +-------------------------+             |
                                              ^                          v
                                              |              +-------------------------+
                                              |              |      Root CA's DN       |
                                              +---------------- Root CA's public key   |
                                        Verify Signature     |   Root CA's Signature   |
                                                             +-------------------------+

The certificate owner is issued the certificate by the CA. It’s signed with the intermediate public key. The intermediate’s certificate is signed with the CA root public key. And the world agrees that the CA root is the ultimate in trustworthiness (until it’s not, of course).

Browsers are loaded with trusted CA Roots and are essentially blessed by the browser creators. When the browser wants to validate a site as authentic (the authentication process), the server provides the chain minus the CA root. It is up to the browser to follow the chain back to the root acquiring keys along the way and then validating the chain by checking signatures. If the signatures all match and the CN matches the hostname, the website has been validated as a trusted endpoint, and further communication may commence.

Requesting Certificates

Certificate Signing Request

Requesting a certificate begins with creating a Certificate Signing Request (CSR). At this point, the private key will also be created based on the criteria provided to the tool that creates the CSR. This tool could be the secured website (vCenter, ClearPass, etc.) or a third-party tool like OpenSSL. There are only two certificate types of consequence: RSA and ECC.

The RSA (Rivest–Shamir–Adleman) public key system is one of the oldest used today. It is typically 2048 or 4096 bits in length. Larger certificates mean longer computational time to encrypt and decrypt.

The ECC (Elliptic Curve Cryptography) certificates work with shorter bit lengths but can take longer to decrypt.

You will be required to provide a significant amount of detail for the certificate. DigiCert has a great online tool to generate the openssl command to create the CSR.

The most important value is the Common Name (CN). This name MUST match the DNS name the server will possess when deployed. If this server will be known by other names, you also add Subject Alternative Names (SANs) later in the process.

The command generated is shown below:

openssl req -new -newkey rsa:4096 -nodes \
-out server_hvcc_edu.csr -keyout server_hvcc_edu.key \
-subj "/C=US/ST=New York/L=Troy/O=Hudson Valley Community College/OU=IIT/CN=server.hvcc.edu"

Request the Certificate

At this point, the CSR will be used to request the certificate from the CA. Remember that the CA’s job is to issue a public certificate that will work with your private key and be signed by an intermediate, which was also signed with a root. This completes the chain.

The CSR is submitted, which includes the public key and all of the field data. The CA takes the certificate and signs it with its intermediate and releases the new certificate. This with the private key gives the complete asymmetric key.

Cipher Suites

First, let’s examine how cipher suites are expressed. The naming convention may vary slightly depending on the server and the software that is performing the encryption. For example, the following are identical but expressed differently.

IANA name:
    TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
OpenSSL name:
    ECDHE-RSA-AES256-GCM-SHA384
GnuTLS name:
    TLS_ECDHE_RSA_AES_256_GCM_SHA384

Let’s take TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 for a test drive and explain what these pieces mean.

 +------------------------------------ Protocol:       Transport Layer Security
 |    +------------------------------- Key Exchange:   Elliptic Curve Diffie-Hellman Ephemeral
 |    |    +-------------------------- Authentication: Rivest Shamir Adleman algorithm
 |    |    |            +------------- Encryption:     Advanced Encryption Standard
 |    |    |            |                              with 256bit key in Galois/Counter mode 
 |    |    |        +---+---+     +--- Hash:           Secure Hash Algorithm 384
 |    |    |        |       |     |
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

The above cipher suite will only work with a certificate that is RSA. For an ECC certificate, it would be something like this.

IANA name:
    TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 
OpenSSL name:
    ECDHE-ECDSA-AES256-GCM-SHA384
GnuTLS name:
    TLS_ECDHE_ECDSA_AES_256_GCM_SHA384

And the breakdown would be

 +-------------------------------------- Protocol:       Transport Layer Security
 |    +--------------------------------- Key Exchange:   Elliptic Curve Diffie-Hellman Ephemeral
 |    |     +--------------------------- Authentication: Elliptic Curve Digital Signature Algorithm
 |    |     |             +------------- Encryption:     Advanced Encryption Standard
 |    |     |             |                              with 256bit key in Galois/Counter mode 
 |    |     |         +---+---+     +--- Hash:           Secure Hash Algorithm 384
 |    |     |         |       |     |
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

So, what does it all mean? Well, a certificate is typically only used to initiate a session – although this is not always true. The detail we must remember is that everyone has the public key and can decrypt anything encrypted by the server. So, additional steps must be taken to provide a safe, secure channel.

The agreed protocol is TLS. After the site has been authenticated (through CN check and chain validation), there are exchanges between the client and server (pre-master secret from the client, the Server Random, and the Client Random). The ephemeral nature of the key exchange over ECDHE means that it’s a one-shot and then disposed of, so it cannot affect past or future sessions. The data exchanged allows both sides to generate the same symmetic key for the encryption of payloads (AES-256-GCM). Finally, all payloads exchanged will have a hash value in SHA-384 format that can be used to validate the decrypted payload as genuine.

Operations Note!

The client browser is also expected to check the validity of the certificate through other means like the Certificate Revocation List (CRL). The use of CRL allows an owner to notify a CA that their certificate may have been compromised and should be put on the naughty list.

The owner will request a new certificate for their site. If the the original private key was compromised, a threat actor could setup a server and, through DNS poisoning, get a browser to navigate to said server and be trusted.

File Formats

CER

This is essentially any file whose extension is .cer. The file contents can be practically anything including PEM, PKCS#12, PKCS#8, PFX

DER

The Distinguished Encoding Rules (DER) format is a binary encoding of X.509 data. This is an uncommon format today. The file extension is typically .der.

PEM

Privacy Enhanced Mail (PEM) is essentially a BASE-64 encoding of otherwise non-printable data surrounded by BEGIN and END tags the define the actual encoded payload. The file extension is typically .pem or .crt.

PKCS#7

This format is similar to CER. It will look internally like a PEM file with BEGIN and END tags and the BASE-64 encoded payload. The file extension is usually .p7b and is often used by Windows and Java.

PKCS#8

The private keys are usually a binary representation of ASN.1 formatted X.509 content. This is often encoded in PEM for portability. The file extension is usually .p8

SPKI

SPKI is an acronym for SubjectPublicKeyInfo. It is very similar to PKCS#8 and is often encoded in PEM for portability. Like PEM, the file extension is typically .pem or .crt.

PKCS#10

This is typically the format of a CSR. It’s a binary representation of ASN.1 formatted X.509 content. This is often encoded in PEM for portability. The file extension is usually .p10

PKCS#12/PFX

This defines a container that can hold the private and public keys and the intermediate key. It can have tags, passwords, etc. The file extension is typically .p12 or .pfx. This was the original Java Keystore format before Java moved to the JKS format.

JKS

The Java Keystore (JKS) is very similar to PKCS#12 but managed with the keytool program provided by the Java JDK.

BASE-64

Configurations

Apache

Apache has a section of the default-ssl.conf file that defined the SSL settings for encryption. The next section is a

SSLProtocol             -all +TLSv1.3 +TLSv1.2
SSLOpenSSLConfCmd Curves secp384r1:secp521r1

SSLCipherSuite          ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
SSLCipherSuite TLSv1.3 TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256

SSLHonorCipherOrder     off
SSLSessionTickets       off
SSLOpenSSLConfCmd DHParameters "/etc/ssl/certs/dh-4096.pem"

SSLUseStapling On
SSLStaplingCache "shmcb:logs/ssl_stapling(32768)"

SSLProtocol             -all +TLSv1.3 +TLSv1.2
SSLOpenSSLConfCmd Curves secp384r1:secp521r1
#SSLCipherSuite          ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384

SSLCipherSuite DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-CHACHA20-POLY1305
SSLCipherSuite TLSv1.3 TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256

SSLHonorCipherOrder     off
SSLSessionTickets       off
SSLOpenSSLConfCmd DHParameters "/etc/ssl/certs/dh-4096.pem"

Still in the default-ssl.conf file, there is a bit more that sets up OCSP stapling. This protocol is an alternative to the CRL.

# after closing the VirtualHost

# OCSP Stapling, only in httpd 2.3.3 and later
SSLUseStapling          on
SSLStaplingResponderTimeout 5
SSLStaplingReturnResponderErrors off
SSLStaplingCache        shmcb:/var/run/ocsp(128000)

Table of contents

Overview

Overview

Certificates

Requesting Certificates

Certificate Signing Request

Request the Certificate

Cipher Suites

File Formats

CER

DER

PEM

PKCS#7

PKCS#8

SPKI

PKCS#10

PKCS#12/PFX

JKS

BASE-64

Configurations

Apache