Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

PKI Components in Junos OS

Learn about PKI components and understand how to manage PKI in Junos OS.

PKI Management and Implementation

The basic PKI elements required for certificate-based authentication in Junos OS are:

  • CA certificates and authority configuration

  • Local certificates including the device’s identity (for example: IKE ID type and value)

  • Private and public keys

  • CRL for certification validation

Junos OS supports three different types of PKI objects:

IKE

The procedure for digitally signing messages sent between two participants in an IKE session is similar to digital certificate verification, with the following differences:

  • Instead of making a digest from the CA certificate, the sender makes it from the data in the IP packet payload.

  • Instead of using the CA's public-private keypair, the participants use the sender's public-private keypair.

PKI over HTTPS

HTTPS support for PKI enhances the security of certificate management operations. The HTTPS on the PKI establishes secure communication channels for SCEP enrollment and CRL revocation, protecting sensitive information.

The PKI process dynamically selects HTTP or HTTPS based on configured URLs, providing flexibility and secure transmissions.

  • If you use a HTTP URL in CA profile, PKID process uses the HTTP communication channel.
  • If you use a HTTPS URL in CA profile, PKID process uses the HTTPS communication channel.

Trusted CA Group

A CA is a trusted third party responsible for issuing and revoking certificates. A trusted CA group is a group of multiple CAs (CA profiles) in one group for a given topology. These certificates are used to establish connection between two endpoints. To establish IKE or IPsec, both the endpoints must trust the same CA. If either of the endpoints are unable to validate the certificate using their respective trusted CA (CA profile) or trusted CA group, the connection is not established.

For example, let's assume you have two endpoints, endpoint A and endpoint B, trying to establish a secure connection. When endpoint B presents it is certificate to endpoint A, the endpoint A will check if the certificate is valid. The CA of the endpoint A verifies the signed certificate that the endpoint B is using to get authorized. When trusted-ca or trusted-ca-group is configured, the device will only use the CA profiles added in this trusted-ca-group or the CA profile configured under trusted-ca to validate the certificate coming from endpoint B. If the certificate is verified as valid, the connection is allowed, else the connection is rejected.

Benefits:

  • For any incoming connection request, only the certificate issued by that particular trusted CA of that respective endpoint gets validated. If not, the authorization rejects the connection.

Cryptographic Key Handling

Cryptographic key handling stores persistent keys in device memory without altering the keys. The internal memory is not accessible to adversaries. You can enable key handling mechanism for cryptographic keys to provide security.

When you enable cryptographic key handling:

  • The cryptographic key handling encrypts keys when not immediately in use.

  • Performs error detection when copying a key from one memory location to another.

  • Overwrites the memory location of a key with a random bit pattern when the key is no longer in use.

A cryptographic administrator can enable and disable the cryptographic self-test functions. However, the security administrator can modify the behavior of the cryptographic self-test functions such as configuring periodic self-tests or selecting a subset of cryptographic self-tests.

The following persistent keys are currently under the management of IKE and PKI:

  • IKE preshared keys (IKE PSKs)

  • PKI private keys

  • Manual VPN keys

Certificate Signatures and Verification

A digital certificate is an electronic means for verifying your identity through a trusted third party, known as a CA. Alternatively, you can use a self-signed certificate to attest to your identity.

The CA server you use can be owned and operated by an independent CA or by your own organization, in which case you become your own CA. If you use an independent CA, you must contact that CA for the addresses of their CA and CRL servers (for obtaining certificates and CRLs) and for the information they require when submitting personal certificate requests. When you're your own CA, you determine this information yourself.

The CA that issues a certificate uses a hash algorithm to generate a digest and then “signs” the certificate by encrypting the digest with its private key. The result is a digital signature. The CA then makes the digitally signed certificate available for download to the person who requested it.

The recipient of the certificate generates another digest by applying the same hash algorithm to the certificate file, then uses the CA's public key to decrypt the digital signature. By comparing the decrypted digest with the newly generated digest, the recipient can confirm the integrity of the CA's signature and, by extension, the integrity of the accompanying certificate. Figure 1 illustrates this entire process.

A certificate is considered valid if the digital signature can be verified and the serial number of the certificate is not listed in a CRL.

Figure 1: Digital Signature Verification Digitally signed certificate process with PKI: CA generates hash, encrypts it with private key, sends certificate with signature. Recipient verifies by comparing hashes.

When DSA signatures are used, the SHA-1 hash algorithm is used to generate the digest. When Rivest-Shamir-Adleman (RSA) signatures are used, SHA-1 is the default hash algorithm used to generate the digest; you can specify the SHA-256 hash algorithm with the digest option of the request security pki generate-certificate-request or request security pki local-certificate generate-self-signed commands. When ECDSA signatures are used, SHA-256is used for ECDSA-256 signatures and SHA-384 is used for ECDSA-384 signatures.

Starting in Junos OS Release 18.1R3, the default hash algorithm that is used for validating automatically and manually generated self-signed PKI certificates is SHA-256. Before Junos OS Release 18.1R3, SHA-1 is used as default hash algorithm.

Certificate Validation

To verify the trustworthiness of a certificate, you must be able to track the path of certified CAs from the one issuing your local certificate to the root authority of a CA domain. PKI refers to the hierarchical structure of trust required for the successful implementation of public key cryptography.

Figure 2 shows the structure of a single-domain CA with multiple hierarchy levels.

Figure 2: PKI Hierarchy of Trust—CA Domain Hierarchical structure showing CA certificates above local certificates with associated private keys, illustrating PKI relationships.

If certificates are used solely within an organization, that organization can have its own CA domain within which a company CA issues and validates certificates for its employees. If that organization later wants its employees to exchange their certificates with certificates from another CA domain (for example, with employees at another organization that has its own CA domain), the two CAs can develop cross-certification by agreeing to trust the authority of each other. In this case, the PKI structure does not extend vertically but does extend horizontally. See Figure 3.

Figure 3: Cross-Certification Diagram illustrating digital certificates and keys in cryptography with CA and local certificates linked to keys for secure communication.