SSL Certificates

SSL certificate encrypt data transmitted over a network. Whenever a user connects to a server using SSL, the server presents the SSL certificate to the user. Afterwards, the device verifies the certificate to ensure that it is valid and issued by a trustworthy certificate authority (CA). Data is securely transmitted over an encrypted connection if the certificate is valid between the user's device and the server. It prevents third parties from intercepting or tampering with the data.

SSL certificates can be created, discovered, and stored in the centralized repository of Key Manager Plus, and requests can be raised for new certificates or domain addition to an existing certificate. Moreover, you are notified when a certificate is about to expire to help you with their timely renewal.

Use Key Manager Plus to:

  1. Create, discover, or import self-signed or CA issued certificates in the network.
  2. Generate Certificate Signing Request (CSR).
  3. Add requests for new certificates or adding a sub domain to an existing certificate.
  4. Receive notifications when certificates are about to expire.

Certificates and CSRs can be generated using either classic or post-quantum cryptography.

Notes:

  • EC 384-bit and 521-bit key sizes are supported from build 7110 onwards.
  • EC 128-bit keys are no longer supported from build 7220 onwards.
  • Post-quantum cryptography is supported from build 7220 onwards.

Following are the classic cryptographic key algorithms:

Following are the post-quantum cryptographic algorithms supported in Key Manager Plus:

Note: Key Manager Plus supports six post-quantum cryptographic algorithm families across two categories: digital signature algorithms, which can be used for certificates and CSRs, and key encapsulation mechanisms (KEMs), which are available only for key pair generation because they do not support digital signatures.

Family

Category

Standard

Parameter sets

Description

ML-DSA

Signature

FIPS 204

ML-DSA-44, ML-DSA-65, ML-DSA-87

Lattice-based digital signatures. Offers small signatures and fast signing, which makes it the recommended general-purpose choice for most certificates.

SLH-DSA

Signature

FIPS 205

12 sets (SHA2 and SHAKE; 128, 192, and 256 bits; S and F variants), for example SLH-DSA-SHA2-128S

Hash-based digital signatures. Security depends only on the underlying hash function, a conservative choice, but signatures are larger and signing is slower.

Composite (hybrid)

Signature

Draft

ML-DSA paired with ECDSA, Ed25519, or RSA, for example MLDSA44-ECDSA-P256-SHA256 and MLDSA44-Ed25519-SHA512

Pairs a post-quantum algorithm with a classical one such as ECDSA. Both signatures must verify, so the certificate stays secure even if one algorithm is broken.

FALCON (pre-FN-DSA)

Signature

Pre-standard

FALCON-512, FALCON-1024

Lattice-based digital signatures with more compact signatures than ML-DSA. Based on a draft standard (FN-DSA), so details may change before it is finalized.

ML-KEM

Key encapsulation

FIPS 203

ML-KEM-512, ML-KEM-768, ML-KEM-1024

Lattice-based key encapsulation for establishing shared secrets between two parties. It is used for key exchange, not for signing certificates.

HQC

Key encapsulation

Pre-standard

HQC-128, HQC-192, HQC-256

Code-based key encapsulation, selected by NIST as a backup to ML-KEM. Based on a different math problem, so it adds diversity if lattice-based schemes are weakened.

Note: FALCON and HQC are experimental algorithms. Certificates using these algorithms may need to be reissued once their standards are finalized.

  1. Discover Certificates in your Network
  2. Create Self-signed Certificates
  3. Certificate Signing Requests
  4. Certificate Signing
  5. Certificate Renewal
  6. Certificate based Operations
Top