In last article, we know the role of clients and their responsibilities for certificate verification. Finally, let's talk about websites. We've discussed many potential issues between CAs and clients concerning certificates, but the most frequent issue is with websites—many websites have faced this problem: certificate expiration.

Websites need to ensure two things:

Ensure their certificate does not expire.
Protect their private key from being leaked. If someone else obtains the private key, the certificate loses its meaning of “only I can prove who I am.” When requesting a certificate from a CA, only the public key is submitted for signing, so only the website should hold the private key.

Remember to update your certificates!

The first point seems straightforward, but many websites have faced similar issues (indicating that most teams are... not well-organized). One hidden aspect is that all certificates have an expiration date, including CA Root and intermediate CA certificates. Websites need to ensure that every link in the certificate chain is not expired.

The challenge with this is that certificates are issued for two years, and after two years… most people will remember to renew (if you've worked in a large company, you might understand how difficult it is to remember “to do something in 2 years”).

So, Let’s Encrypt came up with a brilliant idea: all certificates we issue are valid for only 90 days, with no exceptions! (Clearly, Let’s Encrypt is truly a great organization!)

This approach has two advantages:

The private key, like a password, is changed every 90 days, which is more secure.
Who likes to go through the process every 3 months? This encourages websites to use automated renewal processes, changing certificates every 60 days, which makes issues less likely to occur.

Private Key Protection

The private key is crucial because anyone who obtains it can deceive all clients—claiming to be the website. Thus, ensuring the key is not leaked is essential.

But what if it is leaked? The private key is deployed on servers directly accessible by clients. If the server is attacked, the private key might be leaked. After all, walking by the river, how can one avoid getting their shoes wet!

Revoking Issued Certificates

At this point, you might notice another issue: suppose a website’s certificate has 6 months left, and the private key is leaked, leading to the deployment of a fake website. The methods we've discussed so far can't stop the fake website, as it has obtained the certificate (which can be directly downloaded from the original site and then deployed) and can establish a TLS connection with clients. The certificate is issued by a legitimate CA and is entirely valid.

Clients can only revoke the CA, but revoking a CA is unrealistic—should other sites that haven't leaked their keys suffer as well?

Therefore, we need a mechanism to revoke issued certificates.

There are currently two mainstream methods: CRL and OCSP.

In principle, CA certificates themselves carry this information, informing clients that when verifying a certificate, they should visit this URL list to check if the certificate they are validating is in the revocation list. If it is, they should not trust it.

CRL

In the X509v3 extensions, you can find information about CRL and OCSP addresses. For example, using CRL, you can use the following command to get the CRL address from a downloaded DigiCert certificate:

$ openssl x509 -in digicert_tls_rsa_sha256_2020_ca1.pem -noout -text | grep "X509v3 CRL Distribution Points" -A 4
            X509v3 CRL Distribution Points:

                Full Name:
                  URI:http://crl3.digicert.com/DigiCertGlobalRootCA.crl

Then, download the content from this CRL address (in DER format) and use openssl to decode the DER format to see some of the certificates that this CA has revoked:

$ curl -sS http://crl3.digicert.com/DigiCertGlobalRootCA.crl | openssl crl -inform DER -text -noout

You can view revoked certificates from DigiCert using the CA-provided URL.

OCSP

OCSP works on a similar principle.

But are there any issues with this approach? The client must verify the certificate by making an additional request to the URL to check the certificate's validity, which introduces several issues (using OSCP as an example):

The website's performance will decrease due to the additional time required for CA requests; CA's OCSP servers could become hotspots and might be overloaded by clients.
Privacy concerns: the CA will know which domain names the client has accessed.
Potential security issues: If the CA's OCSP service is down, the client has two choices:
- Ignore verification and continue trusting the target site—this defeats the purpose of OCSP. A certificate holder with a revoked certificate could compromise the CA's OCSP service or block client access to OCSP to continue using their certificate.
- Not trust the target site—this would make the target site unusable due to CA issues, which is unacceptable for the site.

OCSP Stapling

OCSP Stapling can address the above issues. Its core principle is:

The website periodically queries the CA's OCSP service to confirm that its certificate has not been revoked and obtains an OCSP Response.
When a client visits the website, the website provides the OCSP Response along with the certificate, proving that the certificate has not been revoked.

This removes the dependency between the client and CA, resolving the above problems.

But what if the website forges the OCSP Response?

This cannot be forged because the OCSP Response is signed by the CA, and the client must verify this signature to confirm that the OCSP Response is indeed from the CA.

You can use the following command to view the OCSP Response:

openssl s_client -connect kawabangga.com:443 -status -servername kawabangga.com

Here is an example of OCSP Response content:

OCSP response:
======================================
OCSP Response Data:
    OCSP Response Status: successful (0x0)
    Response Type: Basic OCSP Response
    Version: 1 (0x0)
    Responder Id: D5FC9E0DDF1ECADD0897976E2BC55FC52BF5ECB8
    Produced At: Aug 28 12:31:36 2023 GMT
    Responses:
    Certificate ID:
      Hash Algorithm: sha1
      Issuer Name Hash: EC4A2797F8915935139678B3E8C8A21D097B312E
      Issuer Key Hash: D5FC9E0DDF1ECADD0897976E2BC55FC52BF5ECB8
      Serial Number: 4BEA45B1F5C6C0310D047BC9EB5449FA
    Cert Status: good
    This Update: Aug 28 12:31:36 2023 GMT
    Next Update: Sep  4 11:31:35 2023 GMT

    Signature Algorithm: sha256WithRSAEncryption
    Signature Value:
        5c:e0:44:17:a0:84:e1:5d:83:f5:0e:ad:18:2d:da:98:8a:be:
        9d:38:bd:f6:9a:d5:82:c2:14:08:2f:ac:6b:b4:78:4e:25:bc:
        a0:55:19:9b:75:b9:e8:54:d5:79:fa:a8:9b:ab:7a:3f:37:b0:
        9d:8d:f5:d4:67:95:80:e1:cd:bf:d5:ac:5f:fc:8c:22:a7:0f:
        2c:35:0a:de:4f:a9:63:67:ce:59:0f:f1:b7:9d:69:e9:dc:ce:
        06:7b:64:a0:60:19:bf:48:2e:af:f4:5c:85:69:54:4e:71:d0:
        09:75:0d:c5:54:0b:d8:49:1f:bf:18:65:97:03:2d:01:88:bf:
        9b:48:c5:30:f3:f5:59:34:b6:b5:89:81:6f:b0:01:e4:9a:26:
        6b:4d:51:0b:e7:12:86:33:8a:4e:cc:f4:4e:80:b7:63:29:df:
        6c:c6:8b:2e:2f:c1:6f:60:25:7d:4b:5b:4e:9f:48:9d:d0:8a:
        08:25:3d:e2:c0:2c:83:d4:5f:3c:66:4d:0d:71:da:19:c8:b5:
        58:64:b6:98:9f:46:f2:e4:a0:1c:e3:3b:a1:74:59:41:02:51:
        5d:74:43:31:24:02:d2:02:d6:ca:a5:ff:f2:ad:e7:87:89:83:
        40:ec:38:b4:90:1b:92:d3:36:23:f4:71:0d:02:c7:47:14:8f:
        d3:dc:d6:ff
======================================

Thus, if the client receives an OCSP Response from the website, it can directly verify it; if it doesn't receive it, it queries the CA. If received but not validated, the connection is terminated, and the website is not trusted. The only issue is a delay in revocation after the certificate is revoked, which is acceptable.

HTTP Public Key Pinning

Websites can also implement a technique called HPKP (HTTP Public Key Pinning), where the website, in response to client requests, includes an HTTP header called `Public-Key-Pins`. This key is the hash of the certificate's public key. Which certificate? It can be the site's own certificate, an intermediate certificate, or a CA's Root certificate. Once such an HTTP response is returned, it tells the client to only trust that certificate (if pinning the CA's Root certificate, it tells the client to trust only certificates issued by that CA). This helps prevent others from issuing counterfeit certificates.

For example, if our site `super-bank.com` has a strong trust relationship with a CA, but `super-bank.com` is concerned that other CAs might issue certificates for it, `super-bank.com` can pin the CA's Root certificate when clients visit the site. This indicates that the site will only use certificates issued by CA A, and any certificate issued by another CA, even if trusted, is likely counterfeit!

But what if the site needs to change its certificate? The client might not trust it anymore. Therefore, if using HPKP, a backup key must be present; without it, HPKP will not be effective.

Certificate Transparency

Certificate Transparency (CT) is a concept that requires support from clients, CAs, and websites, which is why it is discussed last.

What problem does it address?

CT addresses the issue of CAs erroneously issuing certificates for other websites. Some CAs have notoriously chaotic internal management. For instance, there is an article about how the author managed to obtain certificates for domains like `github.io` from WoSign, a CA that later lost trust from Mozilla and Google due to its problems. WoSign even attempted to appeal, claiming it only served users in China (essentially saying, "Chinese people only scam other Chinese people"), but the appeal was dismissed. A CA that is not trusted cannot control its scope and mismanagement can cause security issues for websites and users worldwide.

To prevent such issues, Google initiated Certificate Transparency. CT aims to address the problem of CAs issuing certificates indiscriminately. For a detailed understanding of CT, their official website provides a clear explanation.

Here’s a simplified explanation of what each party needs to do:

When issuing a certificate, the CA must log the issued certificate in a CT database, and the CT will provide a Signed Certificate Timestamp (SCT). The CA sends the signed certificate, including the SCT, back to the website.
Clients will only trust certificates that have an SCT when visiting websites. This ensures that all certificates trusted by clients are recorded in the CT database.
Websites can monitor the CT database to check if any certificates have been issued for their domains without their knowledge.

In this way, no CA can secretly issue a certificate for a website without the website being aware of it, ensuring that clients are only trusting certificates that are properly recorded and monitored.

This concludes the series of articles about certificate and hope you have learned something here.

Reference: https://www.kawabangga.com/posts/5330