Functions Related to TSF Data

Installing and Importing Private Keys

In most cases, keys are generated on the device (for highest security). But Junos also allows importing a key pair from an external source if needed (for example, migrating a certificate and key from one device to another). This is done implicitly as part of installing a certificate:

• request security pki local-certificate load filename <cert-file> key <key-file> certificate-id <name>

  This command installs a certificate and its corresponding private key into the device’s local certificate store. The key <key-file> option allows the admin to provide the file path to the private key that matches the certificate being loaded. The certificate-id should match the identity intended for this cert (can be a new or existing ID). After running this, the device will have the private key and certificate ready for use.

Deleting and Zeroizing Keys

When keys are no longer needed or must be replaced, the administrator should remove them from the device to prevent unauthorized use. Junos OS provides commands to delete keys and associated certificates:

• clear security pki key-pair ..

  Deletes a stored key pair (and any associated certificate request) from the device’s PKI storage. The administrator can specify a particular certificate-id <name> to remove a specific key, or use all to delete all locally stored keys and certs. This is a destructive action and cannot be undone, so typically it’s done if a certificate is being decommissioned or if the administrator intend to generate a new key to replace the old one. It requires the “clear” privilege level.

• clear security pki local-certificate ...

  It deletes installed local certificates and their keys from the device. For completeness: clear security pki local-certificate certificate-id <name> removes the certificate with that ID and its corresponding private key, clear ... local-certificate all will delete all certificates and keys from the PKI store, essentially resetting the PKI state of the device.

Security note: The clear commands do not provide means to zeroize cryptographic keys. The request system zeroize command is a higher-level command that erases all sensitive data on the router, including configuration and all keys/certificates, returning it to a factory-default state. This is often used to securely decommission or repurpose a device. After zeroize, on next boot the device will generate fresh default keys (like SSH host keys) and have no residual user config.

Generating Asymmetric Key Pairs (PKI Keys)

Let's break down the key management tasks and commands:

For any feature that uses X.509 certificates (for example IPsec VPN), the device needs an RSA or ECDSA key pair. The Junos CLI provides a convenient command to generate a new key pair and associate it with a certificate ID label:

• request security pki generate-key-pair certificate-id <name> size <bits> type <algorithm>

  This operational mode command generates a new public/private key pair on the device for use in the Public Key Infrastructure (PKI). The admin specifies a certificate ID name to label the key (for later reference) along with the key size and type. Supported key types are RSA or ECDSA, and supported key sizes range up to 4096 bits for RSA or up to 521 bits for ECDSA curves. By default, RSA keys are 2048 bits if not specified. This command runs at maintenance privilege level and outputs a confirmation when the key pair is created.

• request security pki generate-certificate-request certificate-id <name> ...

  After generating a key pair, this command is used to generate a CSR (Certificate Signing Request) for that key, to be sent to a Certificate Authority. This takes the key (by certificate-id) and produces a signed request containing the public key and desired subject name. The admin will use this CSR to obtain a signed certificate from a CA. (This step doesn’t change the device state except to create a stored “certificate request” record; the key remains the same.)

  The possible completions for this command are:

  The subject option should be used with appropriate values to generate the CSR.

• Generating SSH Host Keys

  NFX devices use SSH for secure remote CLI access. On first boot, Junos will automatically generate default host key pairs (RSA and ECDSA, etc.). If needed, an administrator can generate or regenerate SSH host keys, although Junos does not provide a single dedicated CLI command for regenerating all host keys at once – typically one would use the Unix shell or a system zeroize (described later) to accomplish this. The supported host key algorithms for SSH include RSA (2048, 3072 and 4096 bit) and ECDSA (p256, p384, p521 curves), and these can be configured via the hostkey-algorithm settings.

  • Configuration:

  • set system services ssh hostkey-algorithm-list [ algorithms... ]

    This configuration option lets the admin specify which host key algorithms the SSH service should offer/use. For example, an admin might restrict host keys to ECDSA only for security. When a new algorithm is added in this list that doesn’t yet have a key, the system will generate the needed host key automatically. Enabling log-key-changes under SSH will log an event whenever an SSH host key is generated or changed, which is useful for audit tracking and required in certain security modes.

  • Manual regeneration:

    If an admin wants to manually generate a fresh host key pair (for instance, after a compromise of the old key), one method is to delete the existing host key file from the shell and let Junos generate a new one upon next SSH service start. Another method is performing a system zeroize (see below) which wipes all configuration and keys (host keys included), forcing new keys on reboot. Juniper’s documentation suggests using the Unix shell ssh-keygen if needed. For example, an admin with root access can do ‘start shell’ then run ‘ssh-keygen -t rsa’ in the shell to create a new RSA key pair for SSH, then configure the system to use it. However, in normal operations, this is rarely necessary unless rotating keys as part of a policy.

Security note: Ensure any old host key is removed or no longer used if the administrator generate a new one, to avoid confusion for clients (they will see the host key changed). The log-key-changes option is recommended to detect unexpected key changes which could indicate tampering.

X.509 Certificate Validation for IPsec

The TOE uses X.509 certificates as defined in RFC 5280. It does not use certificates for trusted updates/executable code integrity, DTLS/TLS (not supported) or OCSP (CRL used for revocation checking), thereby not requiring the corresponding extendedKeyUsage fields mentioned in FIA_X509_EXT.1.1/Rev.

When certificates are used for authentication in IPsec, the certificate validity and revocation checking is performed anytime the certificate is presented for authentication. To validate certificates, the TOE extracts the subject, issuer, subjects public key, signature, basicConstraints and validity period fields. If any of those fields is not present, the validation fails. The issuer is looked up in the PKI database. If the issuer is not present, or if the issuer certificate does not have the CA:true flag in the basicConstraints section, the validation fails. The TOE verifies the validity of the signature. If the signature is not valid, the validation fails. It then confirms that the current date and time is within the validity time period specified in the certificate.

When the TOE is configured to perform a revocation check using CRL (as specified in RFC 5280 Section 6.3) and the CRL fails to download, the certificate is considered to have failed validation, unless the option to skip CRL checking on download failure has been enabled. Revocation checking using CRL is performed for the leaf and ICA certificates.

The TOE validates a certificate path by building a chain of (at least 3) certificates based upon issuer and subject linkage, validating each according to the certificate validation procedure described above. If any certificate in the chain fails validation, the validation fails as a whole. A self-signed certificate is not required to be at the root of the certificate chain.

Loading Certificate Authority (CA) Certificates

For the device to trust a peer's certificate (e.g., in an IPsec VPN), the CA that issued the peer’s cert must be known and trusted by the device. Admins accomplish this by loading the CA’s certificate into the device:

The TOE only treats the root CA as the trust anchor and does not provide the ability to manually designate a CA certificate as a trust anchor.

• request security pki ca-certificate load ca-profile <profile-name> filename <path>

  This command installs a CA’s public certificate into the device’s certificate store. The CA certificate is typically in PEM or DER file format (e.g., a .crt file). The admin specifies a CA profile name as an identifier for that certificate. The filename points to the local file containing the CA cert. After executing this, the CA certificate is stored and associated with that profile name, meaning the device now trusts any certificates signed by that CA (assuming time validity and revocation checks pass).

  Example: Configure a CA Profile

  This example shows how to configure a CA profile.

  Requirements

  No special configuration beyond device initialization is required before configuring this feature.

  Overview

  In this example, the administrator create a CA profile called ca-profile-ipsec with CA identity microsoft-2008. The configuration specifies that the CRL be refreshed every 48 hours, and the location to retrieve the CRL is http://www.my-ca.com. Within the example, the administrator set the enrollment retry value to 20. (The default retries value is 10.)

  Automatic certificate polling is set to every 30 minutes. If the administrator configures, retry only without configuring a retry interval, then the default retry interval is 900 seconds (or 15 minutes). If the administrator do not configure retry or a retry interval, then there is no polling.

  Step-by-Step Procedure

  To configure a CA profile:

  1. Create a CA profile.

  2. Create a revocation check to specify a method for checking certificate revocation.

  3. Set the refresh interval, in hours, to specify the frequency in which to update the CRL. The default values are next-update time in CRL, or 1 week, if no next-update time is specified.

  4. Specify the enrollment retry value.

  5. Specify the time interval in seconds between attempts to automatically enroll the CA certificate online.

  6. If the administrator is done configuring the device, commit the configuration.

  Verification

  To verify the configuration is working properly, enter the show security pki command.

• Updating or Removing CA Certificates

  If a CA certificate expires or needs removal, the admin can remove it. Unlike local certs, there isn’t a specific clear ca-certificate operational command; instead, one would delete the CA profile configuration and then issue a similar clear command or simply not use it. In practice, re-loading a CA profile with a new certificate (e.g., updated CA cert) can overwrite the old one. The exact removal might involve deleting the security pki ca-profile <name> configuration and then clearing any cached cert. (The documentation doesn’t show a direct clear ca-certificate in CLI reference, but clear security pki storage or using the all option in the previously mentioned clear commands would also clear CA certs as they said "all certificates". So clear security pki local-certificate all would indeed remove all certs including CA ones.)

Enrolling and Installing Local Device Certificates

After generating a key pair (see key management above), the next step is typically to obtain a device certificate (an X.509 certificate identifying the NFX device). To manually load a local digital certificate from a specified location, use the following command:

• request security pki local-certificate load filename <cert-file> certificate-id <name> key <key-file>

This command reads an X.509 certificate file and installs it into the device’s local certificate store, associating it with a given certificate-id. The certificate-id should match the one used when the key was generated (or a new label if the administrator is loading both key and cert together). If the corresponding private key is already on the device (generated earlier and labeled with the same certificate-id), the administrator can omit the key option; otherwise, the administrator can include key <key-file> to simultaneously load the private key from a file. The command requires maintenance or security privilege.

Verifying Installed Certificates: After loading, the admin can verify using show commands. For example:

show security pki local-certificate certificate-id <name>

Ensure that an HTTP server providing the CRL files is running on the IP designated as the CRL server.

Below are some steps a Security Administrator can follow if a connection cannot be established during the validity check of a certificate:

1. Check CRL server URL: Verify that the CRL server URL specified in the certificate and TOE configuration are correct and accessible.

2. Test CRL server Connectivity: Try accessing the CRL server URL directly to confirm that the responder is reachable from the network.

3. Check System Time and Date: Ensure that the system time and date are correct, as incorrect time settings can affect certificate validity checks.

4. Check CRL server Status: Ensure that the HTTP server service is up and running.

5. Review Logs: Examine system and application logs for any errors or warnings related to the certificate validation process. These logs can provide clues about what might be going wrong.

Maintaining Certificate Revocation Lists (CRLs)

To ensure the validity of certificates, especially in high security environments, the device should be aware of any certificates that have been revoked by their issuer. This is done via CRLs:. To manually install a certificate revocation list (CRL) on the router from a specified location, use the following command:

request security pki crl load ca-profile <name> filename <crl-file> –

The ca-profile refers to the CA for which this CRL is applicable (same profile name used when the CA cert was loaded). The filename is the path to the CRL file (usually in PEM format). Running this command updates the device’s CRL cache for that CA. Privilege required is maintenance, like other PKI operations.

Note:

To skip CRL checking if the CRL download fails, the administrator need to use the disable on-download-failure option within the CA profile configuration.

Removing Certificates and Keys from the Trust Store

Over time, certificates (and their keys) may need removal: expired, compromised, or no longer needed credentials should be deleted to maintain a clean security posture. As mentioned in Key Management, Junos uses the clear security pki commands to remove entries:

clear security pki local-certificate [certificate-id <name> | all | system-generated] –

Deletes installed local certificates and their associated keys . With certificate-id <name>, it removes the specific certificate identified by that name (and also deletes the corresponding public/private key pair from storage) . Using all removes all local certs, cert requests, and associated keys . The system-generated option specifically removes the automatically generated self-signed certificate (if one exists) . This command requires the “clear” privilege level .

Example: If the certificate with ID “vpnCert” needs to be removed (say it was revoked and we are going to replace it), the admin would enter:

user@device> clear security pki local-certificate certificate-id vpnCert

This deletes the certificate vpnCert and its key from the device’s store .

Removing CA Certificates: To remove a CA certificate, the admin would delete the configuration for that CA profile (if it was configured under [edit security pki ca-profile]) and then could either load a new one or simply leave it deleted. If the CA was loaded only via operational command, using the clear security pki local-certificate all actually also removes CA certificates and CRLs (since it says “all local digital certificates” – likely includes CA storage, though not explicitly stated).

Use case for removal: If a CA was compromised or replaced, the administrator can remove the old CA certificate so the device no longer trusts it.

All these actions can only be performed by an administrator (security or maintenance privilege), ensuring normal users cannot alter trust anchors or certificates. This meets the Common Criteria requirements that only authorized roles manage the TSF data like certificates and keys.

Controlling Cryptographic Functionality and Algorithms

Beyond keys and certificates, administrators often need to control what cryptographic functions and algorithms the device uses. This includes enabling or disabling certain services (like SSH) and selecting or restricting algorithms to meet security policy requirements (for example, disallowing outdated ciphers or enforcing FIPS-approved cipher suites).

Enabling/Disabling Secure Management Services

Secure Shell (SSH): SSH is usually enabled by default on Junos for remote CLI access. Administrators can fine-tune its settings under the [edit system services ssh] hierarchy:

• FIPS mode enforce protocol version to v2 only (which is default).
• Idle timeouts: While not cryptographic per se, configuring an inactivity timeout (e.g., under [edit system login] ) can drop idle sessions.