Navigating the rapid evolution of the encryption we use that is causing problems

The biggest trip-up is a growing number of incompatible systems trying to connect, and it is usually either an age or configuration issue.

To get to what we need to do, you need to understand why, so that we can achieve what we want to keep things working. The why this is happening, is directly due to the increasing computing power via the push of quantum computing on the cusp of decoding the older and existing encryption ciphers. 

Quantum computing is evolving fast and we've been learning what types of problems it is best for. Asymmetric encryption is one it is doing well to crack, including ALL the existing ones currently used.  Public Key Encryption (PKI) is the anchor of TLS (Transport Layer Security, formally SSL) so that our browsing (httpS) and authentication/ID lookup (ldapS) depend on.  PKI is based on those asymmetric algorithms that clearly need to be replaced.

There are two parallel paths being taken to manage this.

• Shortening the key lifetime period
• Creating a new key algorithms and key exchange

Certificate / key lifetime:

If you manage certificates for any publicly visible web and ldap servers, and you don't want errors showing to your visitors, you have to get a certificate from a public CA (Certificate Authority).  In the earliest days, you could get 10-year expiry, but it was soon found that the private keys do occasionally get exposed, after which, whom ever has it can decode everything it was used on. So started the path to reducing the Cert expiry/key lifespan in the age of manual certificate renewal and placement. Manual renewal and placement of certs have always been a bit of pain, so some automation was needed. To fill that need the Let's Encrypt project https://en.wikipedia.org/wiki/Let%27s_Encrypt started that now spans to now being the largest Certificate Authority through to the ACME protocol that is now the Internet Standard RFC 8555 https://www.rfc-editor.org/info/rfc8555/. Let's Encrypt automates 90 and shorter Cert lifespans easily. 

The shrinking Certificate lifespan is enforced by the CA/Browser Forum agreements, where the browsers will only include CA links to those CAs that 

A) conform to the current Maximum Certificate lifespan (going down every year to 47 days in 2029), https://www.ssl.com/article/preparing-for-47-day-ssl-tls-certificates/

B) has the tools to automate the certificate renewal and placement

For your certificates that are entirely internal from an internal CA, this doesn't directly apply, yet.  It will change eventually, even if just newer software not being able to handle manual certificates anymore.  Internal CAs will need mechanisms for overlapping root certs so that we don't have to manually do system wide re-certification process every time like some systems still have.

As the certificate life span shrinks, any system that has the wrong date will increasingly have issues connected to things, as a system that is more than the certificate life span out of sync fails any validation.   Certificate validity date/time range gets important, otherwise we get failures for them being read as not valid.

I wrote up the tools to check these in use previously at https://blog.konecnyconsulting.ca/2026/08/checking-tls-certificates-in-use.html

Quantum resistant certificate algorithms and associated key exchange

The root of the cryptography are the cipher algorithms, and the keys that go with them.  Asymmetric algorithm PKI for the server identity chain, and to negotiate/exchange the symmetric algorithm keys used for the bulk exchange, with frequent changing of those symmetric keys during sessions.

The symmetric algorithms in use are shown to still be strong and resistant to the new quantum computing.  But the asymmetric algorithms in use appear to be readily figured out, i.e. those keys can theoretically be extracted with some experimental success already.  The original Diffie-Hellman cipher algorithms have already been defeated by conventional computing and have already been in phase out for many years. RSA (Rivest–Shamir–Adleman) algorithms have been the mainstay for a long time, but they are the first that are starting to fall to those early quantum computers, and NIST has declared them deprecated and to be phased out in the government by 2030. EC (Elliptic Curves) are the newer, and already widely deployed algorithms, they too have shown they can be cracked by quantum computing, just not as readily as RSA.  The next generation of algorithms aren't ready yet, but they are getting close, and path forward is established.

When a TLS client (web browser or LDAP ID lookup) connects to the TLS server (apache, IIS, AD, eDir), there is a handshake to negotiate which algorithm and cipher they will use, ideally the strongest possibly, but that has been an attack vector in the past, so key exchange mechanics are important.  The current ones have been shown to be vulnerable to quantum computing cracking, so a new key exchange has been defined and is already being rolled out. This new ML-KEM Key Exchange is already live on many big websites and available to any client that supports it. Standard related software such as OpenSSL has supported it since version 3.5. If a client doesn't support ML-KEM Key Exchange, the server will fall back to the older ways until they are removed.  Making sure your systems are updated to use ML-KEM Key Exchange is a big push now to be ready for the next steps, given how long it can take to get all software coded up to date, and then deployed. 

There are two parts on the server side of TLS to manage on this migration.  

1) The software and what ciphers and key exchange mechanisms it supports. This is on the developers to make sure they are rolling out the appropriate code to handle RSA for legacy systems until they are all dealt with, handle EC at the same time for the more updated clients and include running the ML-KEM Key Exchange. 

2) The Certificates placed with those servers, and what certificates are in them.  Current expectation is for the certificates to have both RSA and EC keys in them, so that the strongest can be used by the clients as we make sure they are all using the newest before we can remove the old ones.  In the next year or so we should start adding the new ML-DSA Digital Signature keys once that standard is ratified. 

To check what your systems are doing isn't quite as easy as the first part, as they are a part of the mechanisms that are non-trivial to decode at the packet level, nor do our standard clients expose those details. 

https://testssl.sh/ so far appears to be THE tool to use. The system you run it on will impact tests depending on your version of OpenSSL

grab the most current version, 3.2.3 at time of this writing, and get it onto your work directory of a Linuxish system/vm and expand with

# tar -zxvf testssl.sh-3.2.3.tar.gz

cd to the new directory and run it in a large terminal session for lots of useful data. 

# ./testssl.sh {targetFQDNorIP:port} 

    or with a URI

# ./testssl.sh https://testssl.sh/

   (Note: standard port for HTTPS is 443, for LDAPS is 636, but to works against any TLS connection)

This will show you lots of useful information about that target system, with green being good, red and yellow for their appropriate bad/warning status. 

The results can be overwhelming, but as you learn, it is so useful, and even gives you scores of things that are good (in green or can be changed to blue for the colourblind), warning (yellow), or a real problem(red)

The section of testssl.sh's results that start with "Testing server's cipher preferences" up until the "Testing server defaults (Server Hello)" header are the core for this issue. 

What ciphers are offered, if it has a preference (good) or not (weak), and if the newer quantum ready key exchange is offered. 

Ideally, we want to see the modern strongest Elliptic Curve offered, that we see starting with ECDHE-ECDSA- as well as still (for now) have the other older ones available until we are sure those older clients have been updated.  We want to see TLS1.3 offered, and the only old one being TLS1.2 unless you are supporting really old systems out there.

For key exchange, under "..forward secrecy.."  we want to see some KEMs offered like  

KEMs offered                 X25519MLKEM768    (vs none)

WireShark can see some of the details at the start of the negotiation. The challenge is that we only see a part of the conversation before it shifts to encrypting the rest of the handshake, that you can only read if you have the certificates/keys involved.     

Summary: Things we need to be doing NOW

Make sure everything is synced in time to a central standard 

Enable TLS v1.3

Enable ML-KEM Key Exchange

Automate certificate issuance

Glossary and useful links

PKI:  https://en.wikipedia.org/wiki/Public_key_infrastructure

RSA:  https://en.wikipedia.org/wiki/RSA_cryptosystem

EC:  https://en.wikipedia.org/wiki/Elliptic-curve_cryptography

https://blog.konecnyconsulting.ca/2026/08/checking-tls-certificates-in-use.html

Checking TLS certificates in use

In the efforts to secure communications over TCP/IP, we often have to deal with the certificates that are the keys to the process. Checking that the correct and correctly configured certificate (or cert for short) is the one running, is an essential troubleshooting/validation step. 

The best way where possible is to check the running cert on the running service. Especially that the correct cert that is being used.  Typically, we'd be looking at the dates that it is valid, the name (subject or common name), and the Subject Alternative Name (SAN)

For Web interfaces, a browser is the ultimate testing tool, with Firefox being the (currently in 2026) most consistent to work with, but the general concepts are the same with the others even if done differently.  If there is a problem stopping you from getting to the page, you just have to pause there, because the details are already available. 

Firefox:

For some issues, it will offer you to look at the cert below the scary sounding warning, if so, that is the easy option. Otherwise, if you've accepted the risk already or it is a good cert, you should see a little shield in front of the URL. The shield shows with a checkmark in it for good, or an Exclamation mark (Not Secure) if not.

Click on that shield, and in top right of that sub-window click on "Connection {not} secure" as the case may be.  Select "More site Information" at the bottom, and then View Certificate to see a page with all the details that you can 'print' for your records (usually to pdf or such)

Chrome (and related):

If there is a cert issue stopping you with the dreaded "Your connection is not private", click on the red "Not secure" in front of the URL, where you will see the option for Certificate details to click on, and then look at. The first tab has some useful basics, but often we need to look at the details tab to expand the fields you want to look at, such as to find the Extension of 'Certificate Subject Alternative Name'. The Export option saves an actual public key that can be looked at with tools such as openssl or KeyStore Explorer that we'll discuss further down.

If the cert is accepted as a secure one, click on the slider 'tune' button in front of the URL, click on "Connection is secure", click on the "Certificate is Valid" to see the Certificate details described above. 

Other options:

If you have to do this regularly, there is a GUI tool called  https://keystore-explorer.org/  KeyStore Explorer that works with most GUI. 

For our purposes, select 'Examine', 'Examine TSL/SSL', enter the target host and port, 

With the next page not directly showing the SAN, that is one of the Extensions, where if the cert has a SAN, you see the Extension, and clicking on it shows the value(s)

Linux Systems:

If you are on a Linux system (or can shell into), we can use https://en.wikipedia.org/wiki/OpenSSL openssl from the command line without an install. Other operating systems typically need an install.

 # openssl s_client -showcerts -connect {serverIP|FQDN}:443 |openssl x509 -noout -text |less

 # openssl s_client -showcerts -connect google.com:443 |openssl x509 -noout -text |less

While the default secured web traffic set to port 443, others can readily be used and often are used for administrative interfaces.  Also, there are many other services that use TLS to secure them, and this is where the openssl command and KeyStore Explorer are our most available options to look at them. 

Direct file examination:

 #  openssl x509 -in server.crt -text -noout

or with KeyStore Explorer, 'Examine' from the menu, 'Examine File', browse to the file to be examined.

There are other options and ways, this is just the primer as I found many who need these steps don't know them off of hand, so this is an effort to make it easy. 

Moderation of groups/forums

Keeping a group/forum civil and on track can be quite a challenge.

Moderators have a range of challenges dealing with keeping a group on a track:

• Posters who don't understand what a group/forum is about (its core focus) and post stuff way outside that focus.  Clutter. 
• Bad actors: those spammers/scammers trying to pull attention away to other things that have nothing to do with the group/forum, even if they make their post look superficially like it belongs. I've often seen these go to incompatible or even competing products/services, and beyond to straight out scams and malware. These bad actors are hoping that readers are careless, thinking that those links have been vetted already, and that all vetting is perfect.
• Posters who have a real question or concern, but provide insufficient information about it, assuming the other participants are mind readers. There are often several ways the issue or concern could be taken, so others have to ask clarifying questions back at you to better understand, and as part of vetting your post.  
• Posters who don't speak the same language/culture as the group default/majority.

Tips: 

• If posts get through without being held for review, they have NOT been vetted and can't be trusted like you might others you already know in the group. Look who posted it, and even there could be a masqueraded or compromised account. 
• Even if the content of a group/forum looks all good, and you see active moderation happening, bad stuff still sneaks in and can take some time to be cleared out. Making sure you report such content helps the moderators see it as they aren't in the group 24/7 (most are unpaid volunteers!).
• If a group/forum has lots of out of scope and/or junk content, that is probably a group without active moderation. If it is an area that you'd like to be cleaner and be a part of, try to moderate it by flagging bad content as moderators can't see it all. You might even be invited to help moderate, or you can even offer if there is even someone there who could grant you those technical permissions. 
• If your post is answered with questions, they are usually honest, and jumping back at them makes you appear more like the spammer/scammers. Bad actor posters will often use bullying approach to push their suspicious content through, inviting the wrath of the BanHammer (a range of control moderators have to pause or block bad actors).

Summary:
Groups/forums can be useful and fun, but as with any other human activity, we can have misunderstandings among honest caring people, and we can have bad actors trying to mess things up one way or another. So be ready for the occasional such misunderstanding, because none of us are perfect, whether flesh or artificial.  Being nice is just the least friction path forward, especially for those of us trying to keep the arena of conversation nice.