ON THIS PAGE
 

Troubleshoot Issues in Quantum Safe IPsec VPN

Read this topic to troubleshoot issues in CA certificates, retrieving keys, or establishing tunnels, along with relevant solutions for quantum safe IPsec VPN.

Use this topic to diagnose and resolve certificate, Transport Layer Security (TLS), quantum key retrieval, and tunnel establishment issues in Quantum Safe IPsec VPN deployments.

This topic applies to deployments that use:

  • A firewall providing Quantum Safe IPsec VPN service

  • Quantum Key Distribution (QKD)

  • ETSI QKD APIs

  • X.509 certificates with certificate authority (CA) validation

  • Public key infrastructure (PKI) certificate chains with root and intermediate CAs

  • RSA (2048‑bit, 4096‑bit) and ECDSA cryptographic keys

In QKD deployments, the firewall acts as a Key Management Entity (KME) client and establishes HTTPS connections to the KME server. Before retrieving quantum keys, the firewall validates the KME server certificate chain during the TLS handshake.

To collect diagnostic information, enable PKI and Junos Key Manager (JKM) logging on the firewall:

  • Use PKI tracing for certificate import, certificate-chain validation, and certificate-related TLS failures.

    1. Configure PKI traceoptions to enable logging.

    2. Review the log for errors.

  • Use JKM tracing for QKD or Key Management Entity (KME) connectivity and key-retrieval failures. JKM tracing writes application logs to /var/log/jkm.

    1. Configure JKM traceoptions to enable logging.

    2. Review the log for errors.

Troubleshooting Summary

Review the summary table for an overview of the specific failures discussed in this topic:

Table 1: Specific Issues in Quantum Safe IPsec VPN
Issue Type Root Cause Solution

Certificate and PKI failures

  • Certificate files that use carriage return line feed (CRLF) formatting.

  • Incorrect PEM file structure having multiple certificates in a PEM file

  • Missing intermediate CA certificates.

  • Duplicate certificate identities.

  • Convert certificate files to UNIX line feed (LF) format.

  • Store each certificate in a separate PEM file.

  • Configure the complete CA chain.

See Troubleshoot CA Certificate Load Failure Due to Multiple Certificates in a PEM File.

TLS connection failures

Certificate chain validation fails with HTTP status code 0 or curl response code 60 or the KME server doesn't respond.

Verify the TLS certificate-verification failure. Check hostname mismatches, certificate validation dates, certificate chain details, CA certificate configuration.

See Troubleshoot QKD Key Retrieval Failure Due to Issues in Certificate Chain Validation.
Secure application entity (SAE) identifier mismatch

Firewall SAE identifiers do not match KME SAE identifiers. Although TLS authentication succeeds, ETSI QKD API requests fail to retrieve keys.

Configure matching local-sae-id and peer-sae-ids values on the firewall and the KME. Verify successful key retrieval using ETSI QKD API calls.

See Troubleshoot Key Retrieval Failure Due to SAE Mismatch.

QKD key retrieval failures

  • Key expiration before retrieval.

  • Timing issues between peers (initiator and responder).

  • KME configuration errors.

  • Request rate limiting.

  • Retrieve keys within the required validity period.

  • Validate KME configuration for key availability and key pairing.

  • Reduce request frequency or adjust KME rate limits.

See Troubleshoot QKD Key Retrieval Failure Due to KME Server Error.

Troubleshoot CA Certificate Load Failure Due to Multiple Certificates in a PEM File

Problem

Description

The firewall reads the certificate successfully but fails to load it into a CA profile. The issue occurs during PKI operations when loading a CA certificate into a CA profile.

Symptoms

Symptoms include:

  • The following command displays certificate details but does not load the certificate:

    The command returns the following error:

  • A single PEM file contains multiple certificates. The following output appears when you run the command cat /tmp/certs/ca.pem.

    The PEM file contains multiple certificates. Junos OS requires one certificate per PEM file when loading a CA certificate into a CA profile.

  • Multiple certificates in the chain use the same subject name. The firewall uses the certificate subject name as a unique identifier. If two certificates have the same subject name, the firewall treats the second certificate as a duplicate and does not load it. See [SRX] SRX cannot load two certificates with same Subject at once.

  • The certificate file contains Windows-style CRLF endings, such as \r\n, which can cause PEM parsing issues on the firewall.

Solution

Perform the following steps to resolve the issue:

  1. Ensure that each PEM file contains only one certificate. Avoid combining root and intermediate CA certificates in the same file.

    Use separate files, such as root-ca.pem and int-ca.pem.

  2. Verify that all certificate files use UNIX line feed (LF) line endings before loading the files onto the firewall.

  3. Configure a separate CA profile for each certificate in the trust chain.

    1. Load the root and intermediate CA certificates separately.

    2. Verify that the certificates are loaded.

    3. Verify each certificate individually.

Troubleshoot QKD Key Retrieval Failure Due to Issues in Certificate Chain Validation

Problem

Description

The firewall cannot retrieve QKD keys because TLS certificate validation of the KME server fails.

If certificate validation fails, the TLS handshake does not complete and the key retrieval request fails.

Symptoms

The quantum key manager profile configuration on the firewall is successful. The quantum key manager on the firewall establishes an HTTPS connection to communicate with the KME server for encryption key retrieval. The firewall validates the KME server’s TLS certificate chain using the trusted CAs configured in the quantum key manager profile. However, the TLS connection to the KME server fails, preventing the firewall from retrieving keys from the KME.

The following operational command fails to retrieve keys:

The following logs indicate TLS failure with HTTP status code 0 and curl response code 60.

The quantum key manager profile includes only the root CA:

The HTTPS key request fails during the TLS handshake because the firewall cannot validate the KME server certificate chain.

This issue can occur when the KME server does not provide the required intermediate CA certificate and the intermediate CA certificate is not configured locally. It can also occur when the firewall policy requires the intermediate CA certificate in the local trusted CA store.

Solution

Determine whether the KME server provides the intermediate CA certificate during the TLS handshake. To resolve this issue, configure the firewall to trust the complete certificate chain as shown below:

  1. If the KME server provides the intermediate certificate chain, configure the root CA certificate in the trusted-cas list. Root CA trust is sufficient when the KME server provides the required intermediate certificates.

    If the KME server does not provide the required intermediate certificate, or if the firewall policy requires local intermediate CA certificates, load the intermediate CA certificate and add it to the trusted-cas list.

  2. Verify that the key retrieval is successful after updating the configuration.

    Confirm the logs show a successful HTTP response code and status code 0.

For successful TLS communication, configure the root CA certificate as a trust anchor. Configure intermediate CA certificates locally only when the KME server does not provide them or when the firewall requires them.

Troubleshoot Key Retrieval Failure Due to SAE Mismatch

Problem

Description

TLS communication succeeds, but the firewall cannot retrieve quantum keys from the KME.

Symptoms

You observe the following behavior:

  • From operational mode, enter the following command to view peer device's key manager profile and keys.

    The command fails. JKM requests one key by default. If the KME response does not return the requested number of keys, JKM treats the request as a failure. The operational command displays only the failed status:

    Review the JKM log for the KME HTTP response.

  • From operational mode, enter the following command to view key manager profile details.

    The command returns the following details. The output shows one failed request.

Solution

Align the SAE identifiers on the firewall with the SAE identifiers on the KME. The firewall was initially configured with the SAE IDs SRX01 and SRX02 as local and peer SAE IDs. Perform the following steps to resolve the issue:

  1. Update the firewall key manager profile to use the same SAE IDs configured on the KME. Use SAE_A and SAE_B as the local and peer SAE IDs.

    Key retrieval is successful after aligning the local-sae-id and peer-sae-ids values with the corresponding SAE IDs configured on the KME.

  2. Alternatively, send a Get Key API request to the KME by using the firewall certificate and private key.

For ETSI QKD key retrieval to succeed, the SAE identifiers configured on the firewall must match the SAE identifiers defined on the KME.

Troubleshoot QKD Key Retrieval Failure Due to KME Server Error

Problem

Description

The firewall fails to retrieve QKD keys from the KME due to a server-side error. The problem is not related to Junos OS configuration or TLS validation, but to KME constraints. An HTTP 503 response confirms that the KME did not successfully fulfill the key-retrieval request.

Symptom

You observe the following:

The following command fails:

The firewall sends a request to the KME and receives an HTTP 503 response. Log indicates that the firewall establishes TLS connection and validates the certificate chain. However, the KME server returns an HTTP response code 503, indicating a server-side error.

The internal server error message from the KME indicates that the issue occurs when the KME cannot provide the requested key within the allowed retrieval window. Review the KME logs to determine why the KME rejected or could not process the request. Common causes include:

  • The key is no longer available on the responder-side KME.

  • The allowed key retrieval window—typically less than 10 seconds—has expired.

  • The KME does not have a matching key for the requested SAE pair.
  • Rate limiting due to repeated or delayed requests.

In QKD workflows, the responder must retrieve the key shortly after the initiator. Delayed requests can cause the KME to return HTTP 503.

Solution

To troubleshoot a key-retrieval failure for which the KME returns HTTP 503, review the KME response message in the firewall log.

  • Run the initiator and responder commands back-to-back with minimal delay.

    1. On the initiator, run the following command:

    2. On the responder, immediately run the following command:

  • Verify KME configuration to ensure the following settings on the KME2:

    • The KME2 stores the key for the correct SAE pair. If it does not, the firewall cannot return the key.

    • Key stream distribution configuration is correct; otherwise, KME2 has no key to return.

    • SAE pairing between endpoints is accurate.

    • Limit repeated requests to avoid rate limiting by the KME.

  • If the KME returns temporary backoff responses, retry the key retrieval. If key retrieval returns HTTP 401, correct the client-certificate, authentication, or KME authorization configuration before retrying.

If the TLS validation succeeds but the KME returns HTTP 503, internal server error, the failure indicates a KME issue and did not fulfill the request. Ensure that the responder retrieves the key within the allowed time window. Verify key distribution settings on the KME and avoid excessive requests.

Other Common Issues in Quantum Safe IPsec VPN

Review the following table for other common failures in Quantum Safe IPsec VPN deployments:

Table 2: Common Issues in Quantum Safe IPsec VPN
Issue Type Root Cause Solution

Connectivity failure to QKD device

Loss of IP connectivity between the firewall and QKD device due to VLAN mismatch, storm-control actions, port security violations, DHCP issues, Address Resolution Protocol (ARP) inconsistencies, or switch forwarding problems.

Verify L2 and L3 connectivity. Check VLAN assignments, switch port status, storm-control profile, port-security settings, ARP tables, and routing. Restore stable connectivity before configuring QKD.

Certificate import failure

Unsupported certificate format (DER instead of PEM), passphrase-protected private keys, unsupported key format, incomplete certificate chain, or validation failures when using a self-signed CA.

Before importing certificates into the firewall:

  • Convert certificates to PEM format.

  • Remove private key passphrases.

  • Convert keys to a supported format (for example, PKCS#8)

  • Validate the certificate chain.

Quantum key retrieval failure due to certificate trust validation issues

The KME presents an unknown self-signed root certificate, which leads to TLS validation failure and causes the firewall to reject the connection.

Typical errors include, self-signed certificate in certificate chain and unable to verify the first certificate.

This issue doesn't occur when you configure trusted CAs.

Import the KME root CA certificate into the firewall CA profile and associate the profile with the Quantum Key Manager configuration.

Create a CA profile so that the firewall trusts the KME server certificate: set security pki ca-profile ROOT_CA_PROFILE ca-identity ROOT_CA.

Load the root CA certificate in PEM format using the command, request security pki ca-certificate load ca-profile ROOT_CA_PROFILE filename /var/tmp/root-ca.pem.

After you import the root CA certificate, the firewall can validate the KME certificate chain, establish HTTPS sessions, and retrieve QKD keys successfully.

Verify the CA certificate using the command, show security pki ca-certificate

Related Documentation