↓ Skip to main content
Le Site de François
  1. Index/

OpenSSL

Cryptography Tls Pki Library Tooling Openssl

OpenSSL is an open-source cryptographic library and command-line toolkit, originally derived from SSLeay in 1998 and now governed by the OpenSSL Software Foundation under an Apache 2.0 licence (since version 3.0). It is the default cryptographic substrate for the majority of Linux server software: Apache httpd, nginx, curl, wget, PostgreSQL, MySQL, Postfix, OpenLDAP, and hundreds of other projects link against libssl and libcrypto by default. It implements TLS (all versions from 1.2 through 1.3), X.509 certificate parsing and validation, PKI operations (CSR generation, certificate signing, CRL and OCSP processing), and the full range of cryptographic primitives — symmetric ciphers (AES-GCM, ChaCha20-Poly1305), hash functions (SHA-2, SHA-3, SHAKE), RSA, ECC (ECDSA, ECDH, Ed25519, X25519), HMAC, HKDF, and key derivation functions. The library has two primary components: libcrypto, the algorithm library, and libssl, the TLS protocol layer built on top of it. The openssl command-line tool exposes both as a single swiss-army interface for certificate management, key generation, encryption, hashing, benchmarking, and protocol testing.

OpenSSL’s versioning history is operationally important. Versions 0.9.x through 1.0.2 are end-of-life and contain known vulnerabilities including Heartbleed (CVE-2014-0160, 2014 — an out-of-bounds read in the TLS heartbeat extension that exposed up to 64 KB of server memory per request, including private keys, and triggered a global certificate revocation event). Version 1.1.1 reached end-of-life in September 2023; version 3.0 was the transition that restructured the library into a provider architecture — a plugin model where algorithm implementations are supplied by provider modules (the built-in default provider, the legacy provider for deprecated algorithms, and the fips provider). OpenSSL 3.x is the current supported branch, with 3.0 LTS (end-of-life 2026) and 3.4+ as the actively developed line. The FIPS provider for OpenSSL 3.x has received FIPS 140-3 validation, making OpenSSL 3.x+FIPS the production path for US federal and compliance-mandated deployments. OpenSSL 3.4 added initial support for ML-KEM (FIPS 203) and ML-DSA (FIPS 204) via the default provider, with SLH-DSA (FIPS 205) following in 3.5 — making OpenSSL 3.4+ the primary PQC migration path for the Linux ecosystem. The hybrid TLS 1.3 key exchange group X25519MLKEM768 is supported from OpenSSL 3.4, enabling the already-deployed Chrome interoperability without additional patching.

The openssl CLI is the universal screwdriver for certificate and key operations in the Linux ecosystem, and knowing its most operationally important commands is essential for anyone managing PKI or TLS infrastructure. openssl req -newkey ec -pkeyopt ec_paramgen_curve:P-256 -keyout key.pem -out csr.pem generates an ECDSA P-256 private key and CSR. openssl x509 -in cert.pem -noout -text decodes and displays a certificate’s full contents including SANs, validity, and extensions. openssl verify -CAfile ca-bundle.pem cert.pem validates a certificate chain against a trust store. openssl s_client -connect host:443 -showcerts opens a TLS connection and displays the full certificate chain presented by the server — the most reliable way to diagnose certificate chain issues in production. openssl pkeyutl -sign and openssl dgst handle signing and hashing from scripts. openssl speed benchmarks algorithm performance on the local hardware, producing reference numbers for algorithm selection decisions. For LUKS users, cryptsetup uses libgcrypt rather than OpenSSL, but the conceptual mapping of operations is the same. For cert-manager and Vault, OpenSSL’s algorithm support matrix defines what the underlying certificate operations can produce; the addition of ML-DSA to OpenSSL 3.4 is therefore the dependency that unblocks those tools’ PQC certificate issuance. BoringSSL (Google’s fork) and LibreSSL (OpenBSD’s fork) provide API-compatible alternatives with narrower, more conservative algorithm sets; AWS-LC (Amazon’s fork of BoringSSL) adds FIPS 140-3 validation and ML-KEM/ML-DSA support and is the default in AWS SDK and Rust aws-lc-rs deployments.

Related

ECC (Elliptic Curve Cryptography)

Cryptography Pki Tls Signatures Key-Exchange Pqc
Elliptic Curve Cryptography (ECC) is a family of public-key cryptographic algorithms built on the mathematics of elliptic curves over finite fields. Its security rests on the Elliptic Curve Discrete Logarithm Problem (ECDLP): given a public point Q = k × G on a curve (where G is a fixed base point and k is the private key scalar), recovering k from Q and G is computationally infeasible on classical computers. The practical advantage over RSA is dramatic key size efficiency: a 256-bit ECC key provides roughly the same classical security as a 3072-bit RSA key, because the best known classical algorithms for ECDLP (Pollard’s rho) are exponential whereas the best RSA algorithms (GNFS) are sub-exponential. This size difference has compounding benefits — smaller keys mean faster operations, smaller certificates, smaller TLS handshake messages, and lower power consumption on constrained devices. ECC is now the dominant choice for all new asymmetric cryptography deployments: TLS 1.3 mandates ECDHE for key exchange, and ECDSA or EdDSA for authentication; SSH defaults to Ed25519; code signing infrastructure increasingly uses ECDSA P-256 or Ed25519.

ECDSA (Elliptic Curve Digital Signature Algorithm)

Cryptography Signatures Pki Tls Ecc Pqc
ECDSA (Elliptic Curve Digital Signature Algorithm) is the elliptic curve analogue of DSA, standardised in FIPS 186 and the IETF, that produces digital signatures using a private key and verifies them with the corresponding public key. It is the most widely deployed signature algorithm in X.509 certificates (P-256 with SHA-256 is the default for certificate authorities issuing TLS certificates), in code signing (Authenticode, macOS, Linux package signing), in TLS 1.3 certificate authentication, in SSH host keys and user keys (though Ed25519 is increasingly preferred), and in blockchain and cryptocurrency systems. An ECDSA signature over a message m with private key d on curve with base point G produces a pair (r, s), where r is the x-coordinate of an ephemeral public key k × G and s encodes the relationship between the message hash, r, the private key d, and the nonce k. Verification requires only the public key Q = d × G and is fast; signing requires the private key and a nonce.

ML-DSA (Module-Lattice-Based Digital Signature Algorithm)

Cryptography Pqc Signatures Pki Tls Nist Lattice
ML-DSA (Module-Lattice-Based Digital Signature Algorithm), standardised as NIST FIPS 204 in August 2024, is the primary post-quantum replacement for digital signatures. It replaces ECDSA, EdDSA, and RSA PSS/PKCS#1 signatures in X.509 certificates, code signing, TLS client and server authentication, SSH, JWT signing, and any other context where a party proves possession of a private key by producing a signature that others verify with the public key. ML-DSA is derived from CRYSTALS-Dilithium, the submission that won NIST’s lattice-based signature selection, and its security rests on the Module Learning With Errors (MLWE) and Module Short Integer Solution (MSIS) problems — the same mathematical family as ML-KEM, which is significant because both algorithms can share implementation code and hardware acceleration for the underlying polynomial arithmetic (NTT, number-theoretic transform).