Certificate Authority (CA) Hierarchy¶

A Certificate Authority (CA) Hierarchy is a structured trust model used in Public Key Infrastructure (PKI) to establish the validity of digital certificates. It typically consists of a root authority and intermediate authorities that issue certificates for end-entities (such as servers or users).

Structure of Authority¶

The hierarchy is built to allow a trusted root to delegate the responsibility of issuing certificates to subordinate CAs.

Root CA: The top-level authority, often referred to as the Root CA^[600-developer__tools__security__security-file-extension-name.md]. The public key of the Root CA is the "basis of trust" and is typically embedded directly into operating systems or browsers (e.g., within Windows)^[600-developer__tools__security__security-file-extension-name.md].
Intermediate CA: Entities subordinate to the Root CA. A hierarchy often involves "chain certificates" consisting of Intermediate CAs^[600-developer__tools__security__security-file-extension-name.md]. These CAs are trusted by the Root CA to issue certificates to end-users.
End-Entity: The final recipient of the certificate, such as a web server (e.g., www.sslbuyer.com).

Certificate Files and Formats¶

The certificates issued and managed within this hierarchy utilize specific file standards and extensions to store public keys, private keys, and chain information.

File Types¶

PEM Format: The most common format for certificates (Base64 encoded ASCII). Extensions include .pem, .crt, .cer, and .key. Apache servers typically use this format^[600-developer__tools__security__security-file-extension-name.md].
DER Format: The binary form of a certificate. It does not contain "BEGIN/END CERTIFICATE" statements. Commonly used in Java platforms with extensions like .cer or .der^[600-developer__tools__security__security-file-extension-name.md].
PKCS#7 / P7B: Stores certificates and chain certificates (Intermediate CAs) in Base64 ASCII format. It cannot store private keys^[600-developer__tools__security__security-file-extension-name.md]. Common extensions are .p7b and .p7c.
PKCS#12 / PFX / P12: A binary format used to store the server certificate, intermediate certificates, and the private key in a single, encryptable file^[600-developer__tools__security__security-file-extension-name.md]. This is the standard format used in Windows environments (e.g., for dotnet dev-certs https)^[600-developer__tools__security__security-file-extension-name.md].

Conversion and Management¶

Different systems require different formats. For example, while Linux environments often prefer PEM, Windows uses PKCS#12 (.pfx).

PFX to PEM: To extract the public key from a .pfx file (created by tools like dotnet dev-certs) into a .crt file^[600-developer__tools__security__security-file-extension-name.md]:
```
[OpenSSL](<./openssl.md>) pkcs12 -in localhost.pfx -out localhost.crt -nokeys -nodes
```
PEM to PFX: To combine a private key (server.key) and a certificate (server.crt) into a single .pfx file^[600-developer__tools__security__security-file-extension-name.md]:
```
[OpenSSL](<./openssl.md>) pkcs12 -export -in server.crt -inkey server.key -out server.pfx
```

Certificate Signing Request (CSR)¶

Before a certificate can be issued within the hierarchy, a requester must generate a Certificate Signing Request (CSR)^[600-developer__tools__security__security-file-extension-name.md]. This file acts as the application for a certificate and contains identifying information about the requester^[600-developer__tools__security__security-file-extension-name.md].

CSR Fields¶

The CSR contains the following fields, which must be accurately filled out^[600-developer__tools__security__security-file-extension-name.md]:

CN (Common Name): The domain to protect (e.g., www.example.com or *.domain.com for wildcards).
O (Organization): The legally registered organization name.
OU (Organizational Unit): The company department (e.g., IT).
L (Locality): The city where the organization is located.
ST (State): The state or province.
C (Country): The country code.
Key Size: The cryptographic algorithm and key length (e.g., RSA 2048).

Process¶

Generation: The requester generates the CSR and a private key locally. The private key is kept secret, while the CSR is sent to the CA^[600-developer__tools__security__security-file-extension-name.md].
```
[OpenSSL](<./openssl.md>) req -new -newkey rsa:2048 -nodes -out xxxx.csr -keyout xxxx.key -subj "/C=tw/ST=xxxx/L=xxxx/O=xxxx/OU=xxxx/CN=xxx.xxx.xxx"
```
Signing: The CA validates the request and uses its own key to sign the server certificate^[600-developer__tools__security__security-file-extension-name.md].
```
[OpenSSL](<./openssl.md>) ca -in tempreq.pem -out server_crt.pem
```

Trust Validation¶

Clients (like browsers or curl) validate a server's certificate by ensuring it is issued by a trusted CA in the hierarchy.

Local Issuer Certificate: When a client connects to a server, it verifies the certificate chain up to a Root CA installed in the local trust store^[600-developer__tools__security__security-file-extension-name.md].
SSL Certificate Problems: If a client cannot find the "Local Issuer Certificate" to validate the chain, it will report an error (e.g., Unable to Get Local Issuer Certificate)^[600-developer__tools__security__security-file-extension-name.md].
Troubleshooting:
- Insecure: Bypassing the check (e.g., curl --insecure) is discouraged.
- Specifying CA Cert: Providing the specific certificate (e.g., curl --cacert localhost.crt) allows the client to complete the chain^[600-developer__tools__security__security-file-extension-name.md].

Retrieving Certificates: You can manually retrieve the certificate chain from a live server using openssl^[600-developer__tools__security__security-file-extension-name.md]:

[OpenSSL](<./openssl.md>) s_client -connect example.com:443 -servername example.com -showcerts </dev/null 2>/dev/null | sed -n '/^-----BEGIN CERT/,/^-----END CERT/p' > example.crt

Sources¶

^[600-developer__tools__security__security-file-extension-name.md]

[[PKCS#12]]
[[PEM]]
OpenSSL
[[Public Key Infrastructure]]