I generate certificates pretty often, either for my own website or for work, and I vaguely know what they are: identity verification, encryption, the thing that makes the S in the HTTPS, and so on. I’ve learned some really neat things about certificate while writing this blog. If you’re reading this, I hope this helps you as well.
- Certificate Authority(CA): these are trusted entities that issues digital certificates.
- X.509 certificate: is a digital certificate that uses the widely accepted international X.509 public key infrastructure aka PKI standard to verify that a public key belongs to the user, computer or service identity contained within the certificate. (will talk more about PKI below)
- Certificate chain: This is the order in which the certificate can be trusted, with the root certificate having the highest level of trust.
- Root Certificate: issued by the root certificate authority
- Intermediate Certificate: is a subordinate certificate issued by the trusted root. The result is a certificate chain that begins at the trusted root CA, through the intermediate and ending with the SSL certificate issued to you. Such certificates are called chained root certificates. There are several reasons why having an intermediate certificate is important.
- While the surface area for exploits is increased with intermediate certificates, revoking an intermediate and regenerating another one is an easier process than doing that with a root certificate.
- With intermediate certificates, you are not exposing your root certificate; this results in a decreased likelihood of compromising the root certificate. Having to revoke and regenerate a root certificate can be a pain. Getting that root certificate often requires a lengthy process of verification (paperwork, audits, etc). The CA also need to convince browsers to update their trust store.
- Cross-certificate: is a digital certificate issued by one Certificate Authority (CA) that is used to sign the public key for the root certificate of another Certificate Authority. Cross-certificates provide a means to create a chain of trust from a single, trusted, root CA to multiple other CAs.
- Self-Signed Certificates: Self signed certs are generally used for internal facing applications. It can get quite expensive if you need to purchase a certificate from a CA for every application you run. The disadvantage is that these certificates are not trusted by other applications and there are no advantages offered by the PKI.
- Certificate Types: single domain, wildcards, multiple domain
- Levels of Validation: Domain Validation (DV), Organization Validation (OV), and Extended Validation (EV)
Certificate Signing request (CSR)
Certificate Signing Request(CSR) is a block of encoded text that is given to a Certificate Authority when applying for an SSL Certificate. A private key is usually created at the same time that you create the CSR, making a key pair. I’m not going to discuss generate a CSR in this blog, but I provided a Digital Ocean tutorial in the resources below on how to do that.
A certificate authority will use a CSR to create your SSL certificate (keep your private key secret). The certificate created with a particular CSR will only work with the private key that was generated with it.
Most CSRs are created in the Base-64 encoded PEM format.
-----BEGIN CERTIFICATE REQUEST----- MIIByjCCATMCAQAwgYkxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlh MRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRMwEQYDVQQKEwpHb29nbGUgSW5jMR8w HQYDVQQLExZJbmZvcm1hdGlvbiBUZWNobm9sb2d5MRcwFQYDVQQDEw53d3cuZ29v Z2xlLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEApZtYJCHJ4VpVXHfV IlstQTlO4qC03hjX+ZkPyvdYd1Q4+qbAeTwXmCUKYHThVRd5aXSqlPzyIBwieMZr WFlRQddZ1IzXAlVRDWwAo60KecqeAXnnUK+5fXoTI/UgWshre8tJ+x/TMHaQKR/J cIWPhqaQhsJuzZbvAdGA80BLxdMCAwEAAaAAMA0GCSqGSIb3DQEBBQUAA4GBAIhl 4PvFq+e7ipARgI5ZM+GZx6mpCz44DTo0JkwfRDf+BtrsaC0q68eTf2XhYOsq4fkH Q0uA0aVog3f5iJxCa3Hp5gxbJQ6zV6kJ0TEsuaaOhEko9sdpCoPOnRBm2i/XRD2D 6iNh8f8z0ShGsFqjDgFHyF3o+lUyj+UC6H1QW7bn -----END CERTIFICATE REQUEST----
What does all of this mean?
You can view the Root Certificate Specification here for Entrust Root Certification Authority — G2, with the Entrust Certification Authority — L1K as the intermediate certificate.
- Common Name (CN): The server name that is protected by the certificate, and if it doesn’t match up, you’ll get that lovely message that warns you “Connection is not secured”
- Organization (O) is the organization name
- Serial Number: X.509 certificate serial number, a serial number that distinguishes it from other certificates
- Common Name (CN): The entity that issues the certificate and in this case, it is Entrust Data
It looks like the validity period of this certificate is two years. When I saw this initially, I thought it seem kind of long, so I started detective work and see what’s going.
Apparently, there’s some certificates secret society call the CA/Browser Forum, and they passed the Ballot 193–825-day Certificate Lifetimes which limits the lifetime for a certificate to roughly two years. So why 2 years?
Decreasing the maximum lifetime of certificates to two years helps reduce the presence of older, outdated and possibly vulnerable certificates that were issued before new guidelines were put in place.
When the SHA-1 deprecation was first announced in favor of SHA-256, the validity period was 5 years. That’s a long time (especially in tech) to get people to move over to the new thing. Hence, the two year validity period rule.
A certificate’s fingerprint is the unique identifier of the certificate. The Certificate Fingerprint is a digest (hash function) of a certificate in x509 binary format. It is calculated with the specified algorithm (SHA-1, SHA-2, SHA-256, etc)
The public key infrastructure (PKI) is the secret to how certificates and all that fun stuff interact with one another. The PKI is the foundation that enables the use of technologies, such as digital signatures and encryption, across large user populations.
Let’s Encyypt is awesome. I won’t be talking about it in this blog, but I provided a link below to a DigitalOcean tutorial.
How To Install an SSL Certificate from a Commercial Certificate Authority | DigitalOcean
This tutorial will show you how to acquire and install an SSL certificate from a trusted, commercial Certificate…
Thanks to Electra Chong for sharing the DO link with me