Establishing Trust
Last updated
Was this helpful?
Last updated
Was this helpful?
A client signifies its trust in a particular root Certificate Authority (CA) through a process involving the certificate chain of trust. Here’s how it works:
Pre-installed root certificates: Most operating systems and web browsers come with a set of pre-installed root certificates from trusted CAs. These root certificates are stored in a trusted root store.
Certificate validation: When a client connects to a server (e.g., visiting a website), the server presents its TLS certificate. This certificate is typically signed by an intermediate CA, which in turn is signed by a root CA.
Chain of trust verification: The client verifies the chain of trust by checking if the presented certificate is signed by a trusted root CA. It also checks if the intermediate CAs in the chain are trusted.
Digital signatures: Each certificate in the chain is digitally signed by the CA above it. The client uses the public key of the CA to verify these signatures, ensuring that the certificates have not been tampered with.
Trust decision: If the entire chain of trust is valid and leads back to a trusted root CA, the client trusts the server’s certificate. This allows secure communication to proceed.
For Infrastructure PKIs, a single .
An intermediate Certificate Authority (CA) acquires its certificate through a process called cross-signing by a root CA. Here’s how it works:
Certificate Signing Request (CSR): The organization that wants to set up an intermediate CA generates a CSR. This CSR includes the public key and identifying information of the intermediate CA.
Submission to root CA: The CSR is submitted to a trusted root CA.
Verification: The root CA verifies the identity and legitimacy of the organization requesting the intermediate certificate.
Signing: Once verified, the root CA uses its private key to sign the CSR, creating the intermediate certificate. This signed certificate links the intermediate CA to the root CA, establishing a chain of trust.
Issuance: The root CA issues the signed intermediate certificate to the requesting organization, which can then use it to sign end-entity certificates (e.g., TLS certificates for websites).
This process ensures that the intermediate CA is trusted by virtue of its connection to the root CA, which is already trusted by browsers and operating systems.
A certificate chain, also known as a chain of trust, is a sequence of certificates that ensures the authenticity and trustworthiness of a digital certificate. Here’s how it works:
Verification process: When a client (like a web browser) connects to a server, the server presents its end-entity certificate. The client then checks the certificate chain to ensure each certificate is signed by the next certificate in the chain, up to the root certificate.
Chain of trust: Each certificate in the chain is verified using the public key of the certificate above it. This process continues until the root certificate, which is already trusted by the client.
Trust establishment: If the entire chain is valid and leads back to a trusted root certificate, the client trusts the end-entity certificate, allowing secure communication to proceed.
This system ensures that the end-entity certificate is legitimate and has been issued by a trusted authority, maintaining the integrity and security of digital communications.
The Basic Constraints extension in a digital certificate addresses the problem of distinguishing between different types of certificates and their roles within a Public Key Infrastructure (PKI). Here’s how it works:
Certificate Authority (CA) identification: It specifies whether a certificate is a CA certificate or an end-entity certificate. This distinction is crucial because CA certificates can issue other certificates, while end-entity certificates cannot.
Path length constraint: It can limit the number of intermediate CAs that can exist below this CA in the certificate chain. This helps prevent excessively long certificate chains, which can be inefficient and potentially insecure.
Problems solved:
Preventing unauthorised certificate issuance: By clearly marking which certificates can act as CAs, it prevents end-entity certificates from issuing other certificates, thereby maintaining the integrity of the PKI.
Managing certificate chain length: Limiting the path length ensures that the certificate chain remains manageable and secure, preventing potential vulnerabilities associated with long chains
The Basic Constraints extension in a digital certificate uses the following mechanisms to solve the problems of distinguishing CA certificates from end-entity certificates and managing the certificate chain length:
CA flag: This flag indicates whether the certificate is a Certificate Authority (CA) certificate or an end-entity certificate. If the flag is set to TRUE, the certificate can be used to sign other certificates, indicating it is a CA certificate. If set to FALSE, it is an end-entity certificate and cannot issue other certificates.
Path length constraint: This specifies the maximum number of non-self-issued intermediate certificates that may follow this certificate in a valid certification path. By setting this constraint, the extension limits the length of the certificate chain, ensuring it remains manageable and secure.
How do these mechanisms work:
CA flag: When a certificate is issued, the CA flag is set according to the intended use of the certificate. During the certificate validation process, clients check this flag to determine if the certificate can be trusted to issue other certificates.
Path length constraint: This value is checked during the validation process to ensure that the certificate chain does not exceed the specified length. If the chain is too long, the certificate is considered invalid.
These mechanisms help maintain the integrity and security of the Public Key Infrastructure (PKI) by ensuring that only authorised certificates can issue other certificates and by preventing excessively long certificate chains.