Red Hat Security: Identity Management and Authentication
Describe the certificate ecosystem in a public key infrastructure.
Review the components in a certificate authority chain of trust.
Manage certificate renewals and revocation lists.
A Public Key Infrastructure (PKI) is a set of roles, processes, and policies that allows you to secure end-to-end communication. You can use PKI to issue digital certificates that validate the identity of users, devices, or services. These digital certificates use the SSL/TLS protocol to encrypt the data. IdM uses PKI to manage digital certificates.
Digital certificates are often used in a client-server model of communication. In PKI, certificate authorities issue certificates to an entity. An entity is a company, organization, or a person that owns a DNS domain (usually a website) to serve user requests. A certificate authority ensures that the entity requesting the certificate complies with a set of characteristics and that it is the owner of the domain name for the certificate. A certificate contains information that uniquely identifies the entities in the communication channel.
Public key cryptography, also known as asymmetric encryption, is a method of encryption that uses a key pair to encrypt data. From the key pair, one key is kept private and the second key is made publicly available to anyone who wants to send a message. Asymmetric-encrypted messages are encoded in a format that cannot be read or understood by an eavesdropper. This method differs from symmetric encryption, which uses a single key that is used to encrypt and decrypt the message.
The following features of public key cryptography make it common in secure communications over the internet:
A message encrypted with the private key can be decrypted by using the corresponding public key. This ensures that the message can be publicly available, and you can unequivocally distinguish the message sender.
A message encrypted with the public key can be decrypted by using the corresponding private key. This means that the message can be publicly available, but only the intended recipient can read the message.
For example, a website uses public key cryptography for identification and to encrypt its communication to users. The website uses its private key to sign the certificate request sent to the certificate authority. The website also distributes its public key packaged in a certificate to an internet user that wants to establish communication.
When a user navigates to the website, they verify the authenticity of the website's certificate with the certificate issuer. The website receives and uses the user's public key to ensure that it is sending messages to the same user during the communication lifetime. The user then encrypts a randomly generated string (sometimes called a secret key) by using the website's public key, found in the website's certificate. Any website could have the public key and send it to the web browser, but only the authentic website has the private key that can decrypt this last message.
At this point, users have identified the website and they can trust that the site is authentic and owned by the correct entity. Then, both parties use the secret key to create a session key and exchange symmetrically encrypted messages from that moment forward. Because symmetric encryption is not as strong as asymmetric encryption, the secret key expires in a short period of time. Both parties agree on a new secret key for every new session to maintain communication.
The Secure Socket Layer (SSL) protocol is a deprecated protocol that was widely used to secure internet communication. The Transport Layer Protocol (TLS) protocol is an upgrade and replacement for SSL that uses high-end asymmetric cryptography. TLS is also known as SSL/TLS, or even as SSL because of the popularity of SSL, but the terms are used interchangeably.
SSL certificates use asymmetric cryptography to identify and encrypt communication. The process where both parties identify themselves and exchange messages by using session keys is called a TLS handshake. The TLS/SSL handshake process ensures that only the intended recipient can decrypt the messages.
An entity uses a DNS domain so that users can establish communications with the hosts that provide the required services.
The root domain is the highest hierarchy level of the entity domain name.
For example, in the https://register.mail.example.com URL, example.com is the root domain.
Different categories of certificates might have different trust levels. The type of certificate that an entity requires depends on its needs.
- Domain Validation (DV) Certificates
Domain validation certificates are the most basic industry-standard certificates to enable an encrypted connection (HTTPS) to a website. You can verify that a website has a domain validation certificate by ensuring that the site URL starts with
https://or by ensuring that it shows a padlock icon next to the URL at the top of the browser.These certificates are commonly used for internal or test purposes. Domain validation certificates are not proven to be owned by a formal business and only require a proof of ownership or control over the DNS domain.
- Organization Validation (OV) Certificates
Organization validation certificates are issued to vetted entities that prove to be a legally registered business and not an individual (that can be the case of a domain validation certificate). These certificates provide a higher level of trust than domain validation certificates.
- Extended Validation (EV) Certificates
Extended validation certificates meet additional requirements than organization validation certificates. To receive an extended validation certificate, an entity must pass a more rigorous set of background checks and vetting process.
Additional to the previous categories, certificates are also one of the following types.
Single domain. The certificate is issued to the root domain only and does include subdomains. For example, for a single domain certificate issued to the
example.comdomain, thelab.example.comsubdomain is not verified by the SSL certificate.Wildcard domain. The certificate is issued to an entity that contains an asterisk character (
*) in the domain name. This type of certificate verifies the subdomains that match the base domain name. For example, for a wildcard domain certificate issued to the*.example.comdomain, thelab.example.comandmail.lab.example.comsubdomains are verified. The name matching criteria is similar to a common regular expression.Multi-domain. The certificate is associated with multiple domains including subdomains. These certificates are specially useful when an entity is present in different country code top-level domain, or has different domain names.
Important
Red Hat does not support wildcard certificates in IdM. A wildcard certificate can be useful in many scenarios, but it adds risk to an infrastructure. The compromise of a server that uses a wildcard certificate puts in danger all other servers in the certificate's scope. An attacker with access to a compromised server can impersonate an entity verified by the certificate.
A certificate contains information about the entity that it validates, such as name, location, and validity period. An internet user can verify the authenticity of a website by viewing the certificate and then decide whether to trust the connection. Certificates are issued by a certificate authority (CA), which is a trusted and verified entity that is authorized to issue SSL certificates.
Certificate authorities follow the guidelines defined from the Certification Authority/Browser (CA/B) Forum. The CA/B Forum is a group of certificate authorities, internet operators, and software vendors that define standards and best practices for certification entities.
The CA architecture includes several layers of certificate authorities that form a chain, which is called a chain of trust. You can verify the authenticity of the CA that issued the certificate by using the certificate that was issued to that issuer CA. At the top of the chain is the root CA, also called the trust anchor.
The root CA does not have a certificate provided by a CA, but it has a self-signed certificate. This certificate is installed in web browsers as a trusted authority and it is used to verify entities in the chain. Below the root CA are intermediate CAs. The intermediate CA certificate is signed by the root CA. An intermediate CA can be configured to issue more intermediate CAs, adding links to the chain of trust. The end-entity or server of a chain of trust is the website, organization, or host being validated.
When you navigate to a TLS-protected website, the end-entity certificate is verified against the CA that signed it. That CA is verified by the intermediate CA up to a trusted root CA. If the chain of trust does not contain a trusted CA, then the entity is not trusted and the browser displays a warning.
A CA receives the identity verification requests in the form of a certificate signing request (CSR). A CSR is an encoded file that contains the SSL public key and information about the entity, such as the common name, location, and domain properties from the entity that wants to be verified.
The root CA does not create a CSR because it issues a self-signed certificate, which is a certificate issued and signed by that same CA. Root CA certificates are usually valid for long periods of time. This characteristic is one of the reasons why you should take strict measures to keep its files secured.
As an end entity, you must create a CSR signed with your private key to obtain a certificate from the CA. After the CA reviews the entity information, it issues the certificate signed with its own private key and provides its public key. The sharing of the public key facilitates the verification of the authenticity of the chain of trust. The following diagram demonstrates a common CSR workflow.
In many organizations, it is common that applications and services require certificates to operate.
You can use tools such as OpenSSL or the Certificate Database Tool (certutil) to create certificates.
In a production environment you would not use these tools to manage certificates.
Situations might arise, however, where you need to manage a limited number of certificates when working with small isolated environments or third parties.
Important
Red Hat does not recommend that you use self-signed certificates in your application or service. Limit the usage of these certificates to proof of concept or testing purposes.
OpenSSL requires a configuration file to create certificates.
The default openssl.cnf configuration file is in the /etc/pki/tls/ directory, but you can use a custom configuration file.
OpenSSL uses directories defined in the configuration file to save certificates, keys, and signing requests. In the following output, you can see the overall directory structure of a certificate authority.
[root@host ~]#tree. ├── certs/├── crl/
├── csr/
├── index.txt
├── openssl.cnf
├── private/
└── serial
| Certificate directory |
| Certificate revocation list (CRL) directory |
| CSR directory |
| Certificate database file |
| Custom OpenSSL configuration file |
| Private key directory |
| Database serial number file |
Use the openssl genrsa command to create an RSA private key that uses AES256 as the encryption method.
The default size of the key is 2048 bits which is a good value for end entities because their certificates usually expire in a year.
However, for certificate authorities it is best practice to specify a higher value.
Depending on the expected usage, end-entity certificate keys might not need to be encrypted. The CSR information for the end entity might not match the organization or location information of the intermediate CA. This is a common situation because intermediate CAs might issue certificates to entities in other countries or for other business purposes. The common name of an end entity must be the fully qualified domain name that the entity controls.
The following example demonstrates the creation of an end-entity private key and certificate signing request.
[root@host ~]#openssl genrsa -out private/lab.example.com.key.pem 2048[root@host ~]#chmod 0400 private/lab.example.com.key.pem[root@host ~]#openssl req -config openssl.cnf \-new -sha256 -key private/lab.example.com.key.pem \-out csr/lab.example.com.csr.pem...output omitted... Country Name (2 letter code) [XX]:MXState or Province Name (full name) []:Mexico CityLocality Name (eg, city) [Default City]:Mexico CityOrganization Name (eg, company) [Default Company Ltd]:Red HatOrganizational Unit Name (eg, section) []:LearningCommon Name (eg, your name or your server's hostname) []:lab.example.comEmail Address []:EnterPlease enter the following 'extra' attributes to be sent with your certificate request A challenge password []:EnterAn optional company name []:Enter
The intermediate CA validates the end entity, reviews the certificate request, and issues a certificate. The following example shows the intermediate CA signing process.
[root@host ~]#openssl ca -config openssl.cnf \-notext -md sha256 -extensions end_entity_cert -days 365 \-in csr/lab.example.com.csr.pem \-out certs/lab.example.com.cert.pemUsing configuration from openssl.cnf Enter pass phrase for /root/inter-ca/private/inter-ca.key.pem:InterCA123^Check that the request matches the signature Signature ok Certificate Details: Serial Number: 4096 (0x1000) Validity Not Before: Jan 25 09:41:21 2023 GMT Not After : Jan 25 09:41:21 2024 GMT Subject: countryName = MX stateOrProvinceName = Mexico City localityName = Mexico City organizationName = Red Hat organizationalUnitName = Learning commonName = lab.example.com X509v3 extensions: X509v3 Basic Constraints:CA:FALSENetscape Cert Type:SSL Server...output omitted... X509v3 Extended Key Usage: TLS Web Server Authentication Certificate is to be certified until Jan 25 09:41:21 2024 GMT (365 days) Sign the certificate? [y/n]:y1 out of 1 certificate requests certified, commit? [y/n]yWrite out database with 1 new entries Data Base Updated [root@host ~]#chmod 0444 certs/lab.example.com.cert.pem
You can view the index.txt file to review the entry for the new certificate.
The V at the beginning of an entry means that the certificate is valid.
To review the certificate details, you can use the openssl x509 -noout -text command.
You can also verify the chain of trust of the certificate by using the openssl verify command.
The following example shows the certificate entry in the database file, the certificate content (issuer, validity, and location), and the certificate validation with the chain of trust.
[root@host ~]#cat index.txtV 240125094121Z 1000 unknown /C=MX/ST=Mexico City/L=Mexico City/O=Red Hat/OU=Learning/CN=lab.example.com [root@host ~]#openssl x509 -noout -text \-in certs/lab.example.com.cert.pemCertificate: ...output omitted... Issuer: C = US, ST = North Carolina, O = Red Hat, OU = Learning,CN = rh362 inter CAValidity Not Before: Jan 25 09:41:21 2023 GMT Not After : Jan 25 09:41:21 2024 GMT Subject: C = MX, ST = Mexico City, L = Mexico City, O = Red Hat, OU = Learning, CN = lab.example.com Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) ...output omitted... [root@host ~]#openssl verify -CAfile certs/ca-chain.cert.pem \certs/lab.example.com.cert.pemcerts/lab.example.com.cert.pem: OK
A TLS client, such as a user reading emails, relies on the validity of the certificate to trust the connection.
Users can ensure that the certificate has not been revoked by verifying the CRL that the CA made publicly available.
The crlDistributionPoints parameter in the end-entity extension of the OpenSSL configuration file contains the URL that points to the certificate revocation list.
This value is encoded into the certificate to ease the verification process.
The CA uses the crlnumber file as a database for the CRL sequence.
By default, the CRL expires every 30 days.
This behavior helps ensure that the CRL is regularly renewed.
You can create a CRL by using the openssl ca gencrl command.
[root@host ~]#echo 1000 > crlnumber[root@host ~]#openssl ca -config openssl.cnf -gencrl \-out crl/inter-ca.crl.pemUsing configuration from openssl.cnf Enter pass phrase for /root/inter-ca/private/inter-ca.key.pem:InterCA123^[root@host ~]#openssl crl -in crl/inter-ca.crl.pem -noout -textCertificate Revocation List (CRL): Version 2 (0x1) Signature Algorithm: sha256WithRSAEncryption Issuer: C = US, ST = North Carolina, O = Red Hat, OU = Learning, CN = rh362 inter CA Last Update: Jan 26 05:07:26 2023 GMT Next Update: Feb 25 05:07:26 2023 GMT ...output omitted... No Revoked Certificates. ...output omitted...
You can revoke a certificate even if the certificate or the certificate authority have not been compromised.
You might want to revoke a certificate when the application is no longer in use or when you have issued a new certificate for the application.
When you revoke a certificate, the database file is updated and the certificate entry shows an R (revoked) instead of a V (valid) for the lab.example.com certificate.
The following example shows how to revoke the lab.example.com.cert.pem certificate, and the updated entries in the database and the serial number file.
[root@host ~]#openssl ca -config openssl.cnf \-revoke certs/lab.example.com.cert.pemUsing configuration from openssl.cnf Enter pass phrase for /root/inter-ca/private/inter-ca.key.pem:InterCA123^Revoking Certificate 1000. Data Base Updated [root@host ~]#cat crlnumber1001 [root@host ~]#cat index.txtR240125233527Z 230126052506Z 1000 unknown /C=MX/ST=Mexico City/L=Mexico City/O=Red Hat/OU=Learning/CN=lab.example.com
The CRL is not updated during the certificate revocation operation. If you view the CRL before you reissue it, then it still shows that no certificates are revoked as in the following example.
[root@host ~]# openssl crl -noout -text -in crl/inter-ca.crl.pem
Certificate Revocation List (CRL):
...output omitted...
No Revoked Certificates.
...output omitted...You can reissue the CRL by using the openssl ca -gencrl command.
After doing so, the CRL now shows the revoked certificate with a serial number update.
[root@host ~]#openssl ca -config openssl.cnf -gencrl \-out crl/inter-ca.crl.pemUsing configuration from openssl.cnf Enter pass phrase for /root/inter-ca/private/inter-ca.key.pem:InterCA123^[root@host ~]#openssl crl -noout -text -in crl/inter-ca.crl.pemCertificate Revocation List (CRL): ...output omitted... Revoked Certificates: Serial Number: 1000 Revocation Date: Jan 26 05:25:06 2023 GMT
You can renew a certificate by creating a new CSR with the same specifications. You can also use the same CSR that was used to create the previous certificate. Even if the certificate was revoked, the renewal process is the same.
[root@host ~]#openssl ca -config openssl.cnf -days 365 -notext \-in csr/lab.example.com.csr.pem \-out certs/lab.example.com.cert.pemUsing configuration from openssl.cnf Enter pass phrase for /root/inter-ca/private/inter-ca.key.pem:InterCA123^Check that the request matches the signature Signature ok Certificate Details: Serial Number: 4098 (0x1002) Validity Not Before: Jan 26 06:13:19 2023 GMT Not After : Jan 26 06:13:19 2024 GMT Subject: countryName = MX stateOrProvinceName = Mexico City localityName = Mexico City organizationName = Red Hat organizationalUnitName = Learning commonName = lab.example.com ...output omitted... Certificate is to be certified until Jan 26 06:13:19 2024 GMT (365 days) Sign the certificate? [y/n]:y1 out of 1 certificate requests certified, commit? [y/n]yWrite out database with 1 new entries Data Base Updated
The intermediate CA updates the database and it acknowledges the renewed certificate as a new one.
[root@host ~]#cat index.txtR 240125233527Z 230126052506Z 1000 unknown /C=MX/ST=Mexico City/L=Mexico City/O=Red Hat/OU=Learning/CN=lab.example.com V 240126061319Z 1001 unknown /C=MX/ST=Mexico City/L=Mexico City/O=Red Hat/OU=Learning/CN=lab.example.com [root@host ~]#openssl x509 -noout -text \-in certs/lab.example.com.cert.pemCertificate: ...output omitted... Issuer: C = US, ST = North Carolina, O = Red Hat, OU = Learning, CN = rh362 inter CA Validity Not Before: Jan 26 06:13:19 2023 GMT Not After : Jan 26 06:13:19 2024 GMT Subject: C = MX, ST = Mexico City, L = Mexico City, O = Red Hat, OU = Learning, CN = lab.example.com ...output omitted...
References
For more information about the CA/B Forum, see https://cabforum.org/
For more information about SSL, see Linux Journal
For more information about SSL and PKI, see Linux.com
For more information about certificate authorities, see Digicert
openssl(1) man pages
For more information about wildcard certificates, see Avoid Dangers of Wildcard TLS Certificates and the ALPACA Technique
For more information about wildcard certificates, see RFC 6125
