As we saw in our post on Symmetric And Asymmetric Cryptography, asymmetric key pairs can be used to encrypt and digitally sign documents, but have a huge shortcoming: since they are just keys, they don't provide the metadata necessary to enable people to securely identify their owner. As we saw in the post on GNU Pretty-Good Privacy, GPG addresses this shortcoming by wrapping the key into a container object (the GPG key) that also embeds some metadata about the owner of the key. Of course also the IETF addressed this problem, defining the standard for X.509 certificates (currently X.509v3). X509 Certificates Howto & Public Key Infrastructure Tutorial explores X.509 certificates and how they are trusted by the means of a Public Key Infrastructure.
X.509 Certificates
The X.509 is the part of the X.500 standard (the old fashioned DAP) that deals with authentication - that part of the standard has been taken outside its initial scope to be used to create documents that provide an identity string.
A certificate however contains a lot of metadata: when using openssl, you can easily print the contents of an X.509 certificate into human readable format by using the "x509" subcommand with the "-text" option.
For example, to print the contents of the "/tmp/foo.crt" certificate, type:
openssl x509 -noout -text -in /tmp/foo.crtan example output is as follows:
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 4098 (0x1002)
Signature Algorithm: ecdsa-with-SHA256
Issuer: C = CH, ST = Tessin, O = Carcano SA, CN = CARC I100T
Validity
Not Before: May 2 05:00:31 2023 GMT
Not After : May 1 05:00:31 2024 GMT
Subject: C = CH, ST = Tessin, O = Carcano SA, CN = www.baz.org
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
04:73:df:7c:ec:a7:00:52:ea:43:f2:f1:c4:9f:7f:
08:d3:04:d3:70:2b:2b:0c:75:43:eb:12:b4:35:ca:
24:91:09:0a:d7:9a:5f:b2:f9:4f:57:7c:62:75:ce:
b9:1c:c0:a2:55:15:0e:d4:09:9f:15:cb:40:00:48:
2c:8a:cf:33:55
ASN1 OID: prime256v1
NIST CURVE: P-256
X509v3 extensions:
X509v3 Subject Key Identifier:
89:5D:31:70:B7:26:4B:5F:D4:F0:83:FF:F6:52:A0:51:77:70:D5:78
X509v3 Subject Alternative Name:
DNS:www.baz.org, DNS: baz.org
X509v3 Authority Key Identifier:
keyid:0B:E7:E4:44:B4:9D:C6:FF:65:96:36:8E:CE:63:4D:D7:43:BF:26:77
DirName:/C=CH/ST=Tessin/O=Carcano SA/CN=CARC R100T
serial:10:01
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage: critical
TLS Web Server Authentication
X509v3 CRL Distribution Points:
Full Name:
URI:http://www.test.carcano.local/crl/carc_i100t.crl CRL Issuer:
DirName:C = CH, ST = Tessin, O = Carcano SA, CN = CARC I100T
Authority Information Access:
OCSP - URI:http://ocsp.test.carcano.local:8889
CA Issuers - URI:http://ca.test.carcano.local/carc_r100t.cer
X509v3 Certificate Policies:
Policy: 1.3.6.1.4.1.1234.1.1
CPS: http://www.carcano.local/ca/cps.html
User Notice:
Explicit Text: Carcano SA Certification Practice Statement
Policy: 2.23.140.1.1
User Notice:
Explicit Text: Extended Validated
Signature Algorithm: ecdsa-with-SHA256
Signature Value:
30:81:88:02:42:01:1f:d0:b4:d8:ed:f3:4f:ba:eb:77:d3:b6:
02:ac:b0:75:e7:30:5d:66:65:78:5f:f3:84:19:0a:f5:5e:17:
4a:6d:53:85:ff:8a:2f:15:22:75:92:bc:1e:8f:7b:97:6e:77:
9e:9f:f5:8e:cb:74:6b:13:2d:3e:0e:14:cf:f1:4b:1f:e1:02:
42:00:83:ae:e0:75:f5:37:eb:f7:ff:cc:86:c0:cb:32:b3:8b:
9e:76:e1:52:96:0e:4d:2d:69:98:16:74:ee:08:ea:33:18:7a:
41:73:6c:c3:16:2a:5d:b0:b3:28:a1:c7:1f:63:13:39:cc:c6:
35:21:da:cc:c2:e6:6d:c0:d9:e9:cd:6f:91The above one is a private certificate issued by a private Certificate Authority: it is a very nicely structured certificate, since it contains the very most of the x509v3 extensions you may find on certificates when working. For this reason, we will refer to its contents along all this post.
The Subject
The subject is the string that provides the identity inside the certificate. Since it is derived from the X.500, the tokens in the subject string strongly recall the names of some LDAP attributes:
- C: Country
- S: State
- L: Location
- O: Organization
- OU: Organisational Unit
- Common Name: the actual identity of the X.509 object
For the same reason, the format relies on ASN.1 syntax.
The Subject is printed among the textual information of the certificate.
In our example certificate, it is:
Subject: C = CH, ST = Tessin, O = Carcano SA, CN = www.baz.orgSome special certificates such as Extended Validation certificates or Organization Validated certificates, may provide additional attributes that help to better identify the subject, such as:
- jurisdictionOfIncorporationCountryName (OID: 1.3.6.1.4.1.311.60.2.1.3)
- jurisdictionOfIncorporationStateOrProvinceName (OID: 1.3.6.1.4.1.311.60.2.1.2)
- jurisdictionOfIncorporationLocalityName (OID: 1.3.6.1.4.1.311.60.2.1.1)
- businessCategory (OID: 2.5.4.15)
- serialNumber (OID: 2.5.4.5)
- streetAddress (OID: 2.5.4.9)
- postalCode (OID: 2.5.4.17)
The Public Key
A certificate contains the public key of an asymmetric key-pair: since this key is a public object, it is perfectly safe to add it to the certificate: the public key attached to the certificate is then exploited to perform cryptographic tasks such as encipherment and verification of digital signatures.
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
04:73:df:7c:ec:a7:00:52:ea:43:f2:f1:c4:9f:7f:
08:d3:04:d3:70:2b:2b:0c:75:43:eb:12:b4:35:ca:
24:91:09:0a:d7:9a:5f:b2:f9:4f:57:7c:62:75:ce:
b9:1c:c0:a2:55:15:0e:d4:09:9f:15:cb:40:00:48:
2c:8a:cf:33:55
ASN1 OID: prime256v1
NIST CURVE: P-256The Signature (Signed or Self-Signed Certificates)
Digital Certificates are pretty similar to real life certificates:
- as in real life, the certificate must be signed
- as in real life, you can self sign a certificate
As in real life, self signed certificates are issued by the subject itself, whereas third party certificates are issued by Authorities: when talking about digital certificates, the authority is called Certificate Authority - CA for short.
Signature Algorithm: ecdsa-with-SHA256
Signature Value:
30:81:88:02:42:01:1f:d0:b4:d8:ed:f3:4f:ba:eb:77:d3:b6:
02:ac:b0:75:e7:30:5d:66:65:78:5f:f3:84:19:0a:f5:5e:17:
4a:6d:53:85:ff:8a:2f:15:22:75:92:bc:1e:8f:7b:97:6e:77:
9e:9f:f5:8e:cb:74:6b:13:2d:3e:0e:14:cf:f1:4b:1f:e1:02:
42:00:83:ae:e0:75:f5:37:eb:f7:ff:cc:86:c0:cb:32:b3:8b:
9e:76:e1:52:96:0e:4d:2d:69:98:16:74:ee:08:ea:33:18:7a:
41:73:6c:c3:16:2a:5d:b0:b3:28:a1:c7:1f:63:13:39:cc:c6:
35:21:da:cc:c2:e6:6d:c0:d9:e9:cd:6f:91The Issuer
As we said, the certificate can be issued either by the subject itself - it is a self-signed certificate in this case - or by a third part subject.
Issuer: C = CH, ST = Tessin, O = Carcano SA, CN = CARC I100TThe Life Time
Same way as in real life, an X.509 is valid from the date it is signed for the requested amount of time, ... typically days or years - this is actually the lifetime of the certificate: when expired, the certificate is no longer valid.
Validity
Not Before: May 2 05:00:31 2023 GMT
Not After : May 1 05:00:31 2024 GMTIt is straightforward that it is needed to have a way to invalidate a certificate before its expiration is reached if necessary: an example use case is if the certificate and its private key get stolen.
For this reason, two revocation status have been designed:
- Revoked, when the revocation is permanent
- Hold, when the revocation is temporary
If someone steals a private key, it is of course wise to revoke the certificate, but if the key is simply lost (for example for accidental deletion) it is reasonable to set it on hold for some time to see if the key gets somehow recovered for example from a backup. If the key is definitively lost, then the certificate must be marked as "revoked".
There are two different ways to verify if a certificate has been put on hold or revoked: the Client can download the Certificate Revocation List (CRL) from the CRL Distribution Point of the Certificate Authority that signed it, or it can query the online OCSP responder endpoint, directly asking the status of the certificate without having to download the whole CRL - we will see both of them in details shortly.
POlicy Constraints
The certificate explicitly claims the constraints that must be enforced when validating its extensions.
There are only two constraints:
the CA's Policy claims the condition as mandatorily required
the CA's Policy advise the condition as nice to be met, but not mandatory
Extensions
X.509v3 provides several extensions: here we list only the ones you are more likely to find on certificates.
Basic Constraints
Basic constraints are used to specify if the certificate is used by a Certificate Authority to sign the issued certificates, and optionally the maximum allowed distance for considering the certificate valid when validating its trust chain - we will discuss in more details the trust chain later on, when talking about the Public Key Infrastructures.
There are only two basic constraints:
- CA: can be either "true" or "false"
- Path-Length: it specifies how long can be the trust chain - it if it longer than specified, the certificate is marked as invalid
Of course, also Basic Constraints can be marked either Critical or Non Critical, and of course the best choice is "Critical".
X509v3 extensions:
X509v3 Basic Constraints: critical
CA:FALSESubject Key Identifier (SKID)
This is simply the hash of the public key attached to the certificate: it is used to be available in the certificate to easily uniquely identify the key the certificate is bound to.
X509v3 extensions:
X509v3 Subject Key Identifier:
89:5D:31:70:B7:26:4B:5F:D4:F0:83:FF:F6:52:A0:51:77:70:D5:78Authority Key Identifier (AKID)
This is used to identify the private key of the CA used to sign the certificate - a Certificate Authority can have more than just one key and certificate indeed: for example, when renewing the CA's certificate, it is both possible to re-use the same key or generate a new one.
The contained values can be any or both of the following:
- an explicit key identifier, set in the keyIdentifier field - this is the value of the subjectKeyIdentifier of the signer certificate, so when validating a trust chain the keyIdentifier of the certificate must match the subjectKeyIdentifier of the certificate used to sign it.
- an issuer (set in the authorityCertIssuer field) along with the serial number identifying the signer certificate (set in the authorityCertSerialNumber field).
X509v3 extensions:
X509v3 Authority Key Identifier:
keyid:0B:E7:E4:44:B4:9D:C6:FF:65:96:36:8E:CE:63:4D:D7:43:BF:26:77
DirName:/C=CH/ST=Tessin/O=Carcano SA/CN=CARC R100T
serial:10:01Key Usage
The certificate explicitly specifies a set of purposes the key is subjected to: for example, a certificate used by a web server needs the "Digital Signature" and "Key Encipherment".
Valid purposes are as follows:
generate digital signature for entity authentication and data origin authentication with integrity
verify digital signatures to provide a non-repudiation service
encryption of keys: used by protocols such as SSL and S/MIME to exchange symmetric keys
encryption of data - in contrast to the previously described encryption of keys
necessary when dealing with exchanging public keys to derive ephemeral keys (for example Diffie-Hellman)
the subject's public key is used to verify the signature on certificates. This extension can be used only in CA certificates
the subject's public key is used to verify a signature on revocation information, such as a Certificate Revocation List (CRL)
the public key can be used only for enciphering data while performing key agreement - requires the Key Agreement usage to be set along with it
the public key can be used only for deciphering data while performing key agreement - requires the Key Agreement usage to be set along with it
Mind the specified constraint applies to the list as a whole: this means that you cannot set a specific constraint for each single listed key usage.
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Key EnciphermentExtended Key Usage
To overcome the limitation of specifying a single constraint that affects the whole list of key usages, to better refine the key usages, they added the "Extended Key Usages" extension. This extension can. be specified multiple times, and so enables you to specify a constraint for each single occurrence.
Valid usages are as follows:
an alias for Digital Signature, Key Encipherment or Key Agreement
an alias for Digital Signature and/or Key Agreement
an alias for Digital Signature
an alias for Digital Signature, Non-Repudiation, and/or Key Encipherment or Key Agreement
an alias for Digital Signature and/or Key Encipherment or Key Agreement
an alias for Digital Signature and/or Key Encipherment or Key Agreement
an alias for Digital Signature and/or Key Encipherment or Key Agreement
an alias for Digital Signature, Non-Repudiation.
During validation, if a certificate contains both a critical key usage field and a critical extended key usage field, both fields must be processed independently, and the certificate be used only for a purpose consistent with both fields. If there is no purpose consistent with both fields, the certificate must not be used for any purpose.
X509v3 extensions:
X509v3 Extended Key Usage: critical
TLS Web Server AuthenticationSubject Alternate Names (SANs)
It provides a way to specify one or more alternative (non-X.500) names. It can be used in addition to the certificate's subject name.
Here you can list:
- Internet electronic mail address (SMTP)
- DNS name
- IP address (both IPv4 and IPv6)
- uniform resource identifier (URI)
Despite the old RFC-5280 states the SubjectAlternateName is an optional add-on, and so both the CN and SubjectAlternateName were checked, the more recent RFC 6125, published in 2011, says that if the SANs is present, then the validator must check SAN first and skip validating the CN.
The consequence is that you must alway put the value in the CN inside the list of SubjetAlternateNames.
If the certificate's subject field is empty, then this extension must be marked critical.
X509v3 extensions:
X509v3 Subject Alternative Name:
DNS:www.baz.org, DNS: baz.orgOther Extensions
There are of course other extensions, but I postpone explaining them when talking about the Public Key Infrastructure (PKI), since they are used by it and so it is easier to understand their purpose after explaining how a PKI is structured.
The Encodings
The certificate can be either encoded using;
- Distinguished Encoding Rule - DER: (the raw binary format)
- Privacy Enhanced Mail - PEM (a base-64 encoded format derived from the raw DER - the advantages brought by the base-64 encoding is being printable).
The Formats
X509 certificates and kes can be stored in several formats
PKCS#1
It is the traditional and default format used by OpenSSL for keys.
It has the following header and footer:
-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-256-CBC,9AA41915E12E28466900B2BC60801ACA
iCuAcJLGrCiD0nYNIu8R+N82epcaZRat0uUqLBUIYpLAKO7xPqqYBBZZ4IMyRSdy
...
nYVRrEhvW0M44ddNxU/vL/7wx+qN17vCuYBLqj+ducrVGvavMSAWBFUwFO9WQNZI
-----END RSA PUBLIC KEY-----The type of the key is specified after the BEGIN keyword, for example RSA, DSA, ECC.
PKCS#8
It is a format for keys that provides a stronger encryption.
It has the following header and footer:
-----BEGIN PRIVATE KEY-----
MIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQDJmQE5X3J4ESMi
...
L3I3+g8AvaydlMr/4omJvqnz8M5SFmAEOBXPEu7p1XKs/+QiTQ1I2+/wNWXlCABw
-----END PRIVATE KEY-----PKCS#7
It can be used to store one or more certificates within the same file - since it does not support storing the private keys of the certificates, this format is convenient only to create trust store files, that is files containing a chain of certificates to be used when validating leaf certificates.
PKCS#12
It provides a password-protected container suitable to store one or more certificates along with their private key.
Mind openssl supports only one certificate and private key per PKCS#12 file!
Components Of A Public Key Infrastructure (PKI)
The actual trust of the certificates is inherited from the certificate they have been signed, going up one level at time, until the root of the chain is reached. This happens when a self-signed certificate is found.
The management of this trust chain is operated through a Public Key Infrastructure (PKI) built using the following components.
Asymmetric Key Pair
A pair made of a private key and a public key mathematically related to one another. They can be used to cipher, decipher and to digitally sign documents. If you are interested in a thorough explanation on cryptographic keys, don't miss the "Cryptography quick guide – Understand Symmetric And Asymmetric Cryptography And How To Use It With OpenSSL" post.
X.509 Certificate
As we saw, it is a digitally signed document with a defined lifetime, containing metadata and a public key of the entity contained in the subject of the certificate. The signature can belong to the private key linked to another certificate or to the one linked to the certificate itself (self-signed certificate).
Secure Storage
A secure facility (typically cryptographic algorithms, but also hardware tokens if necessary) used to securely store the private keys - a stolen key and certificate are very harmful - the abuse is not limited to hijacking a service or Man-in-the-Middle attacks: it the stolen key belongs to a Certificate Authority it can be used also to sign rogue certificates.
Registration Authorities (RA)
An entity that receives Certificate Signing Requests (CSR), validates them in compliance with the Certification Practice Statement (CPS): if the request is valid, then the Registration Authority forwards the CSR to the Certificate Authority to generate the signed certificate. The last step is sending back to the requestor the requested signed certificate.
Certification Practice Statement (CPS)
Among the information that can be published into an X.509 certificate there is the Certificate Practice Statement: this is a statement of the practices the Certification Authority employed when issuing it, as well as the ones that will be used when suspending revoking and renewing, in accordance with specific requirements (i.e., requirements specified in this Certificate Policy, or requirements specified in a contract for services).
Some elements of a CPS may include are documenting practices of:
- issuance
- publication
- archiving
- revocation
- renewal
As an example, you can have a look at the RIPE's CPS.
CPS are broadly used by global Authorities, enabling the end user to know how strong was the validation process the certificate's owner had to undergo to get the certificate.
X509v3 extensions:
X509v3 Certificate Policies:
Policy: 1.3.6.1.4.1.1234.1.1
CPS: http://www.carcano.local/ca/cps.html
User Notice:
Explicit Text: Carcano SA Certification Practice StatementCertificate Authorities
Entities owner of a private key and a Certificate that can be used to generate certificates from Certificate Signing Requests, signing the certificates with the Certificate Authority's private key. As we saw, a CA certificate must have the "CA" basic constraint marked as "critical".
When dealing with private Certificate Authorities, the Registration Authority is often fully automated, providing an authenticated endpoint (such as a REST service) where the submitted CSR is immediately forwarded to the Certificate Authority that instantly signs the certificate. This of course enables the Registration Authority to immediately send back the certificate.
The most used certificate enrolment protocols are:
originally developed by Cisco, now RFC 8894, it is probably the most popular of these protocols: it enables automatic enrolling by submitting the request to a shared secret protected endpoint.
described in the RFC 7030, it is very similar to SCEP, but it relies on mutual TLS authentication, a feature that is gradually raising its reputation over SCEP
described in RFC 8555, it is very similar to SCEP, it also installs a certificate management tool, which generates a key pairing used to validate both the CA and the organization. After being validated, the management tool will generate and sign CSRs and submit them to the CA.
Microsoft proprietary, used for auto-enrolling Active Directory Managed Devices with certificates
Validation Authorities (VA)
A Validation Authority is an entity providing the technical facilities (such as web services endpoints) necessary to make sure a certificate has not been revoked.
Certificate Revocation Lists (CRL) X.509 extension
This extension provides the URL of the CRL endpoint(s): this is the most legacy facility, indeed it is no longer mandatory to provide them, despite many Certificate Authorities still do.
This facility is a service, such as an HTTP server, that provides a file containing the list of the certificates revoked along with the revocation reason.
This service has two major weakness:
- the client must download the file containing the full list: on big Certificate Authorities, after some time this file can become quite heavy, so impacting on the overall performance of the SSL handshaking
- since they contain only revoked certificates, if an issuing CA gets compromised, they do not protect against rogue certificates, since it is not possible to know if a certificate has actually been issued by the "real" one or a rogue one that is using a stolen private key and certificate.
Mind by the way that certificate Revocation Lists do not contain expired certificates: they are already invalid, so there is no reason to list them.
The CRL file must be digitally signed by the Certificate Authority, or by a special delegated certificate that has been signed by the Certificate Authority (indirect CRL). Since signing is a computational intensive task, to minimize response latency, CRLs are pre-generated so that when the CRL endpoint is queried it just has to serve the pre-computed reply. For this reason, the file contains also the scheduled date for the next time the list will be generated again.
X509v3 extensions:
X509v3 CRL Distribution Points:
Full Name:
URI:http://www.test.carcano.local/crl/carc_i100t.crl CRL Issuer:
DirName:C = CH, ST = Tessin, O = Carcano SA, CN = CARC I100TOCSP Responders
It is an online facility that can be queried to directly check the status of a certificate. This addresses both the weakness of the CRL we saw: the size of the reply is very small compared to the size of a whole CRL, and if the certificate has not been issued by the CA the query clearly reports that the certificate is unknown to that Certificate Authority. The OCSP reply must be digitally signed by the Certificate Authority, or by a special delegated certificate that has been signed by the Certificate Authority. Since signing is a computational intensive task, to minimize response latency, CRLs are pre-generated so that when the CRL endpoint is queried it just has to serve the pre-computed reply.
X509v3 extensions:
Authority Information Access:
OCSP - URI:http://ocsp.test.carcano.local:8889OCSP Stapling
The OCSP alone anyway has still some problems: since it is queried by the client, it must be always available to serve requests.
Anyway this ideal requisite hits with the real life world::
- OCSP is a plain text protocol, and some public hotspots and captive portals forbid unencrypted traffic
- OCSP responses can be intentionally blocked during malicious attacks
With these premises, it is clear that a "hard" validation process that marks the certificate as invalid if no OCSP response is received is not a viable option. Even worse, a "soft" validation, that fails only if you receive an OCSP response that claims the certificate has been revoked, works only with honest people, which is like honey for bad guys.
OCSP stapling has been specifically designed to overcome this problem: it enables the server itself to provide the current OCSP reply for its own certificate: this way the client has all it needs to perform a quick and reliable verification of the server certificate.
The server can either:
- fetch OCSP response on the fly when a client negotiate a specific certificate
- periodically pre-fetched the responses all the certificates used by the endpoints it provides - this last option is far more performing
responses are cached until they expire, so to avoid continuously querying the OCSP responder.
There is still one problem: since clients have a preference for "soft" fail, an attacker that has been able to steal a certificate and its key may configure a rogue server that does not provide OCSP stapling, and also block OCSP responses from the OCSP responders.
To address this, a certificate can be marked as "must staple": this is a hint to the client to say that the server always provides OCSP staple for that certificate, and so not to trust it if they do not receive OCSP responses.
Automation Protocols
It is certainly worth to mention it do exists automation protocols such as Certificate Management Protocol (CMP) - (described in RFC 4210) and Certificate Management over CMS (CMC) - (RFC 5273) that operate throughout all the lifecycle of the certificate: conversely from protocol such as SCEP, they manage also certificate revocation.
Authority Information Access X.509 extension
The Authority Information Access (AIA) is an X.509 v3 certificate extension that can provide two types of information:
- the URL of the endpoint from where the client can get a copy of the issuer certificate, that is the certificate of the signing Certificate Authority. This is useful when the client does not have this certificate in its trust store, and the server provides only the leaf certificate without a copy of the signing certificate. Mind anyway that applications leveraging on old libraries may not have the capability of automatically retrieving the certificate
- the URL of the OCSP responders that can be queried to get the current revocation status of the certificate
Authority Information Access:
OCSP - URI:http://ocsp.test.carcano.local:8889
CA Issuers - URI:http://ca.test.carcano.local/carc_i100t.cerThe Trust Model
The trust model used to validate digital Certificates is very similar to the one used to validate real life certificates:
- as in real life, certificates signed by a trusted third party are trusted
- as in real life, self signed certificates are trusted as an exception
So all the above claims apply to digital certificates too: the trust of a certificate relies on the trust assigned to the certificate that signed it. The obvious consequence is that the ROOT certificate of this chain must be self-signed, and so must be explicitly marked as trusted.
Certificate Hierarchy
So basically by the hierarchical perspective there are three kind of certificates:
- ROOT - as the name suggests, they are the root of the chain, they are self-signed by design and they belong to Certificate Authorities.
- INTERMEDIATE - as the name suggests, they stay in the middle, so they have both an ancestor and children certificates - so also these certificates belong to Certificate Authorities.
- ENTITY - even here the name is meaningful: certificates of this kind are used to identify entities, such as users, hosts and so on - the very most of the entity certificates are signed by a Certificate Authority, but it is possible to generate self-signed entity certificates.
- PROXY - these special certificates can be issued by ENTITY certificates, for example for delegating purposes. They can be easily identified because they have the special Proxy Certificate Information (PCI) extension and they are signed by the ENTITY certificate. The standard allows placing in the PCI any type of policy statement expressed in any language (such as eXtensible Access Control Markup Language) .
Proxy certificates are essential in Grid Security Infrastructure (GSI), but the framework is weak when it comes to revoking them: since they are not issued by a Certificate Authority, they don't have the validation facilities that enable them to revoke them before they expire. For this reason it is wise to issue proxy certificates with the lifetime as short as possible, lasting only the necessary amount of time to complete the task they have been created for.
ENTITY certificates and PROXY certificates must have the "CA" Basic Constraint set to "false".
TrustStore
A trust-store is a repository of trusted certificates: the intended use is to store only ROOT certificates that are trusted, but technically it is possible to store any kind of certificate inside them.
System-wide Trust-Store
Typically there is a system-wide trust-store, delivered and kept current by the Linux distribution, and it is used as the initial trust point to validate the certificate chain of TLS enabled services or user certificates.
On a Red Hat (and derivatives) Linux system it is possible to add custom CA certificates to the system-wide trust-store by using the "update-ca-trust" command line utility: simply copy the PEM encoded certificate file to the "/etc/pki/ca-trust/source/anchors" directory and type:
sudo update-ca-trust enable
sudo update-ca-trust extractAfter running those two statements, the certificate is added to the system-wide trust-store, and also to the other trust-stores extracted (synchronized) from it.
You can then easily verify that the certificate is trusted using the openssl command line utility with the "verify" verb.
For example, if you added the "/tmp/FooCA.crt" certificate to the system-wide trust-store, simply type:
openssl verify /tmp/FooCA.crtthe output must be as follows:
/tmp/FooCA.crt: OKDedicated Trust-Store
Unfortunately, there have been several episodes of Certificate Authorities issuing rogue certificates by mistake, because they have been cheated by scammers. For this reason, when dealing with use cases demanding a very strong security, you may need to avoid trusting even the very most (or even all) the public Certificate Authorities: this can be achieved by creating custom trust-stores containing only the minimal set of ROOT certificates you can trust, and configure specific applications to use that trust store instead of the system-wide one.
A pitfall of dedicated trust-store are certainly stateful SSL proxies: when connecting through them they replace the original certificate of the accessed service with a rogue one, so as to be able to inspect the traffic. This means that you must add the certificate of the SSL proxy server to the trust-store, so that the rogue certificates issued by it are valid - adding it to the system-wide trust-store won't be effective, since the application is not using it. If your application is installed on mobile systems, there's a very high risk to have them connected to a network with a stateful SSL proxy sooner or later, so you must provide to the user an easy way to add the certificate of that SSL proxy to the dedicated truststore.
The Trust-Chain
While validating a certificate, it is attempted to build a chain of trust from the certificate that is validated iterating from the certificate to the issuing one checking if the signer certificate is trusted.
As we saw, a certificate in the Authority Key Identifier x509v3 extension provides the Subject Key Identifier of the certificate used to sign it and optionally the name of the ROOT Certificate Authority that marks the beginning of the chain.
Reissuing Certificates Using The Same Private Key
Since the Subject Key Identifier is computed from the key, it is technically possible to re-use the same CSR to issue the same certificate multiple times: the outcome is actually the same certificate (same subject and the same Subject Key Identifier), but with a new expiration time.
Anyway, mind that this is not a safe choice from the security perspective: the expiration date on certificates is used to promote rotating private keys, since keeping the same key for too long increases the chance of having the key broken by bad guys.
Cross-Signing
Being able to reuse the same CSR means also being able to generate multiple copies of the same certificate for example to have the certificate not only self-signed, but also signed by another Certificate Authority.
This practice is called "cross-signing" and can be exploited to address some use cases.
For example, you can create a brand new ROOT Certificate Authority with its own self-signed certificate and send the same Certificate Signing Request used to generate the self-signed certificate to an already existent and trusted Certificate Authority. The outcome is another copy of the same certificate, this time already trusted by systems since it is signed by an already trusted Certificate Authority.
Are you enjoying these high quality free contents on a blog without annoying banners? I like doing this for free, but I also have costs so, if you like these contents and you want to help keeping this website free as it is now, please put your tip in the cup below:
Even a small contribution is always welcome!
You can then immediately start generating and delivering certificates using the self-signed certificate, and take your time for a relaxed delivery of it to the trust-store of your systems: since both the name and the Subject Key Identifier of both certificates match, these systems are already able to build a trust path that initially leads to the already trusted CA. Later, when the self-signed certificate is delivered to the system's trust-store, the trust path will stop at the self-signed certificate.
Another typical use case of cross-signing is keeping valid the certificates issued by an intermediate certificate after the expiration of the root certificate that signed it: you create a new ROOT CA, submit the already existing CSR of the intermediate CA to the new CA to get a cross-signed intermediate certificate. Then you deliver both certificates: the ROOT certificates to the system-wide trust-stores of your systems and reconfigure your services adding the cross-signed intermediate certificate the the certificate bundle (leaf certificate + intermediate certificate).
Caveats And Pitfalls Of The Trust Model
Certificate Authorities just issue certificates to requestors, but unless they have a special policy that requires them to do accurate enquiries on the requestor, they just issue the certificate without special validation checks.
The broadly used basic condition to be met for having a certificate issued is just to be the owner of the domain the certificate is valid for.
This means that it is perfectly right for Certificate Authorities to issue a certificate requested by an entity for a domain with a name very close to the ones of a financial company, if the requestor actually owns it. It is straightforward how this can be exploited to attempt various kinds of fraud and scam.
These kind of misunderstandings deeply impacts on both service providers as well as end users:
- service providers may have to deal with fraudulent sites they don't even know to exist, and so they won't cope. This can of course severely damage their reputation, and so their business
- end users risk to trust malicious websites only because they are using a valid certificate and because they have a name very close to the one of the service they are thinking to use
What can be stolen with this kind of trick spans from credit cards, online banking credentials and so on.
There are a few mitigations that have been attempted to cope with this.
Certificate Practice Statement And Entity Validation Baselines
The first and most obvious mitigation is standardising the Certification Practice: this way Certificate Authorities must follow at least the same baseline when issuing a specific kind of certificate.
CabForum specifically designed a few documents with baselines the CA must comply with.
Standard Practices Of Validation Of The Entities Contained In The Certificate
Another mitigation is standardising a few practices of validating the entities that the requestor put in the CSR, and that are so copied into the issued certificates.
Domain Validated (DV), Individual Validated (OV), Organization Validated (OV) And Extended Validated (EV) Certificates
Cab Forum's designed baselines with the following four validation policies:
the CA's Policy just requires to ensure the requestor owns the domain of the requested certificate - it is of course the most basic kind of validation available.
This validation is accomplished by using one or more Domain Control Validation (DCV) methods - they varies from Certificate Authorities, but the most common ones are adding a TXT record with a specific value or sending an email with a validation code to the administrative email of that domain (usually either admin@ administrator@ postmaster@ webmaster@ hostmaster@ ). Some CA can require you to put a specific file on the web server of that domain.
DV certificates must cleanly publish the CA's CPS used for it, as well as the Cab Forum's OID "2.23.140.1.2.1" (Compliant with "Baseline Requirements – No entity identity asserted")
the CA's policy requires to make sure the name of the requestor is actually the claimed one: this means that the certificate must provide the "surname" and the "givenName" attributes, along with a minimum set of attributes necessary to locate him.
IV certificates must cleanly publish the CA's CPS used for it, as well as the Cab Forum's OID "2.23.140.1.2.3" (Compliant with "Baseline Requirements – Individual identity asserted")
the CA's policy requires to make sure the name of the requestor organization is actually the claimed one: this means that the certificate must provide the "organization" attribute, along with a minimum set of attributes necessary to locate it.
OV certificates must cleanly publish the CA's CPS used for it, as well as the Cab Forum's OID "2.23.140.1.2.2" (Compliant with "Baseline Requirements – Organization identity asserted")
this kind of validation use a dedicated baseline called "Certificate issued in compliance with the Extended Validation Guidelines":
An EV certificate must provide the following (validated) attributes:
- organizationName
- businessCategory
- for any of the attribute Country, State or Locality the related jurisdiction attribute
- the Subject Registration Number - this means that the CA is required to make sure the entity actually exists in the public trade registry
EV certificates must cleanly publish the CA's CPS used for it, as well as the Cab Forum's OID "2.23.140.1.1"
The validation policy used when issuing the certificate is then put into the certificate and it is printed among the Certificate Policies extension.
For example:
X509v3 extensions:
X509v3 Certificate Policies:
Policy: 2.23.140.1.1
User Notice:
Explicit Text: Extended ValidatedFor some years web browsers turned the address bar into green when the supplied certificate was an Extended Validated one. They stopped after realising that it was misleading : people were mixed up and thought that they could definitely trust that entity because of the "green" certificate. They didn't understand the concept - that green only meant that the Certificate Authority thoroughly checked the accuracy of the information supplied in the certificate: these checks anyway have not anything to deal with the fact that the business of the "ACME Philanthropists Inc." that requested the certificate consisting in stealing or doing the worst possible things.
Despite all the attention Certificate Authority use when validating the data written in the certificates, it happened that some of them have been cheated and released rogue certificates, or even worse, released certificates to a requester that was not the individual stored in the certificate data - yes, this is what is called "identity fraud".
Don't think that the risk of having rogue certificates issued belong only to small companies: in December, 2013, Google announced they noticed unauthorised digital certificates issued for several Google domains by an intermediate CA linking back to a French Certificate Authority.
That authority said the incident was caused by human error, but it is worth mentioning that CA has been reported to work with French intelligence. Are you worried now? You should. It depends on your needs, but for some use cases it may be better to rely on GPG and its web of trust - if interested in this topic, please read "A Quick, Easy Yet Comprehensive GPG Tutorial". By the way, they are more social, since they periodically have signing parties.
Certificate Pinning And Key Pinning
The most straightforward solution to the problem of rogue certificates accidentally issued by public Certificate Authorities is pinning one or more certificates or public keys in the chain.
Pinning indeed mitigates the following risks:
- Certificate Authority compromise
- Certificate mis-issuance
- SSL Stripping
There are several libraries that can be used to implement pinning: on iOS you can use Alamofire or NSURLSession, whereas on Android you can use Network Security Configuration or OKHTTP and CertificatePinner.
You can of course configure these libraries to ignore pinning when dealing with certificates issued by locally imported Certificate Authorities: this way they do not block the connection when stageful inspection HTTPS proxies are used.
The pinned set, advertised into headers along with a max-age attribute, is enforced during validation until the max-age is reached.
The maximum security level is achieved by pinning the leaf certificate (or its public key), but you can of course pin the intermediate and the root or even only the root. As you can easily guess, the most secure setup is also the most cumbersome and error prone by the maintenance perspective.
Mind that despite pinning public keys (actually it is their SHA256 being pinned) is more easy to maintain compared to pinning certificates, it is however a very cumbersome and error-prone technique.
In addition to that, it has the shortcomings of being unable to change key until max-age is expired: the client enforces the cached pinning information until max-age expires indeed, so replacing a certificate, either because it is expiring or because a revocation is almost impossible.
HTTP Public Key Pinning
This is a deprecated attempt of creating a protocol to implement key pinning on HTTP traffic. It was adopted by some sites and browsers for a few years, until they hit against how hard and cumbersome it is maintaining it: even a small mistake can make a site completely inaccessible indeed. In addition to that, despite this hasn’t been observed yet, if somehow somebody would be able to obtain a valid certificate for the domain, it is theoretically possible for him to set up an intentionally hostile pinning to take the site hostage. For this reason the browsers gradually deprecated this protocol.
CAA DNS Record
Another way to prevent the risk of rogue certificates issued by public CA by mistake is adding a CAA record to the DNS of your domains: the CAA record is used to advertise which Certificate Authorities are allowed to issue certificates containing that domain name. It was standardised in 2013 by the RFC 6844 .
You can inspect the CAA record of a domain even by using the old fashioned "dig" command line utility.
As an example, let's see what they did at Google:
dig google.com CAA +shortthe outcome is as follows:
0 issue "pki.goog"Certificate Transparency (CT)
The capability of actively blocking non compliant SSL sets was of course the strength of HTTP Public Key Pinning, but it was also the cause of being so sensitive and dangerous if not properly managed. Probably for this reason they moved from an active approach to a passive one, based on tracking on public logs Certificate Authorities' activity: if anything weird would be in this log, this time the necessary actions are taken by humans: this passive approach is certainly slower, but it prevents service outages.
This tracking is called Certificate Transparency (CT): it was proposed by Google, but it quickly became an IETF open standard for monitoring and auditing digital certificates.
The auditing relies on public logs where the global available CA submits each issued certificate. They must publish into at least two public Certificate Transparency logs: by monitoring these logs Companies can easily and quickly identify mistakenly or maliciously issued certificates.
Here are some of the most popular interfaces to CT logs in the web:
- https://censys.io
- https://crt.sh
- https://google.com/transparencyreport/https/ct
- https://developers.facebook.com/tools/ct
Public logs are ... public: this obviously means that anybody has free access to them. This means that special care must be taken when registering certificates: if for example a corporate want to request a certificate for a brand, and don't want people to know that brand belongs to them, it must use a different corporate name if they have, or request someone else such as a trustee to do it for them.
Footnotes
Here it ends this post dedicated to x509 Certificates and Public Key Infrastructures - I know, this is different from my usual posts, since it is completely theoretical. If you want to see all of this in action, don't miss the next post "OpenSSL CA tutorial - A full-featured OpenSSL PKI".
I hate blogs with pop-ups, ads and all the (even worse) other stuff that distracts from the topics you're reading and violates your privacy. I want to offer my readers the best experience possible for free, ... but please be wary that for me it's not really free: on top of the raw costs of running the blog, I usually spend on average 50-60 hours writing each post. I offer all this for free because I think it's nice to help people, but if you think something in this blog has helped you professionally and you want to give concrete support, your contribution is very much appreciated: you can just use the above button.
2 thoughts on “X509 Certificates Howto – A Public Key Infrastructure Tutorial”