{"slug": "rustls-turns-on-post-quantum-ml-dsa-certificates-by-default-and-the-web-pki-cant", "title": "Rustls Turns On Post-Quantum ML-DSA Certificates by Default, and the Web PKI Still Can’t Use Them", "summary": "Rustls 0.23.44, released Monday, enables post-quantum ML-DSA certificates by default with the aws-lc-rs provider, but public web PKI certificate authorities do not yet support the algorithm, limiting immediate impact to private certificate hierarchies. The update also tightens SSL key log file permissions to owner-only read access.", "body_md": "*Version 0.23.44 flips the switch on the aws-lc-rs provider. Whether anyone can act on it depends entirely on who runs your certificate authority.*\n\nRustls, the TLS library that has quietly become the default choice for anything security-sensitive written in Rust, shipped 0.23.44 on Monday with a headline change worth pausing on: post-quantum ML-DSA certificates are now enabled **by default** when you use the aws-lc-rs crypto provider. Not behind a feature flag, not opt-in. On.\n\nML-DSA is the Module-Lattice-Based Digital Signature Algorithm, NIST’s standardised lattice signature scheme and the intended long-term replacement for RSA and ECDSA. Its appeal is not purely defensive. Key generation, signing and verification are all fast, in some operations faster than the elliptic-curve maths it replaces, and unlike RSA it does not fall over to a sufficiently large quantum computer running Shor’s algorithm.\n\n## The catch is the certificate authorities\n\nHere is the part that keeps this from being a bigger story than it is: [as Phoronix notes](https://www.phoronix.com/news/Rustls-0.23.44-Released), ML-DSA certificates are not supported in the public web PKI. No public CA will issue you one. Turning the support on by default does nothing at all for a browser talking to a website, because there is no chain of trust on the other end that speaks the algorithm.\n\nWhere it does matter is private certificate hierarchies, and that is a larger slice of the internet than it sounds. Internal service meshes, mTLS between microservices, device fleets, VPN infrastructure, anything where an organisation runs its own root and issues its own leaves. Those operators do not need to wait for the CA/Browser Forum to agree on anything. They can start issuing lattice-signed certificates whenever their tooling supports it, and as of this release a large chunk of the Rust ecosystem does.\n\n## Harvest now, decrypt later\n\nThe usual argument for moving early is that encrypted traffic captured today can be stored and broken later, once the hardware exists. That argument is much stronger for key exchange than it is for signatures. A signature only has to resist forgery while it is still valid, so a certificate that expires in ninety days is not really at risk from a quantum computer that might show up in the 2030s.\n\nWhat signatures buy you is migration time. Swapping the algorithm underneath a certificate hierarchy touches issuance, validation, monitoring, every piece of middleware that parses a chain, and every embedded client that was compiled five years ago and will never be updated. Organisations that start that work now find the broken pieces on their own schedule rather than under a deadline.\n\n## The smaller change worth noticing\n\nThe other item in 0.23.44 is unglamorous and probably more immediately useful: the SSL key log file is now created with owner-only read permissions. That file contains the session secrets needed to decrypt captured TLS traffic, which is exactly why it exists for debugging, and exactly why a world-readable copy sitting on a shared box is a bad afternoon waiting to happen. Tightening the default costs nothing and closes a real hole.\n\nNone of this is a finished migration. ML-DSA signatures and public keys are considerably larger than their ECDSA equivalents, which means bigger handshakes and more bytes on the wire, and that cost lands hardest on constrained devices and high-connection-rate services. Rustls turning the support on by default does not resolve any of that. It just means the option is now sitting there for anyone who controls both ends of the trust chain and wants to start finding out what breaks.", "url": "https://wpnews.pro/news/rustls-turns-on-post-quantum-ml-dsa-certificates-by-default-and-the-web-pki-cant", "canonical_source": "https://hwbusters.com/news/rustls-turns-on-post-quantum-ml-dsa-certificates-by-default-and-the-web-pki-still-cant-use-them/", "published_at": "2026-09-08 09:00:00+00:00", "updated_at": "2026-09-08 13:25:15.458388+00:00", "lang": "en", "topics": ["artificial-intelligence"], "entities": ["Rustls", "aws-lc-rs", "ML-DSA", "NIST", "Phoronix"], "alternates": {"html": "https://wpnews.pro/news/rustls-turns-on-post-quantum-ml-dsa-certificates-by-default-and-the-web-pki-cant", "markdown": "https://wpnews.pro/news/rustls-turns-on-post-quantum-ml-dsa-certificates-by-default-and-the-web-pki-cant.md", "text": "https://wpnews.pro/news/rustls-turns-on-post-quantum-ml-dsa-certificates-by-default-and-the-web-pki-cant.txt", "jsonld": "https://wpnews.pro/news/rustls-turns-on-post-quantum-ml-dsa-certificates-by-default-and-the-web-pki-cant.jsonld"}}