SSL Certificate Management Tools

[AaronFaby]

Hi all,

Now that SSL/TLS certificates will have shorter lifespans, managing all of the certs that are in use by an organization is going to be even more important. 

I wanted to see what everyone is using to automate the discovery and management of certificates. I am aware of Venafi, but was looking for some alternatives or perhaps some open source options.

Thanks!

[Caute_cautim]

@denbesten There are two problems: In the USA, Europe and Australia. There are mandates to change all critical infrastructure to migrate existing Public Key Infrastructure algorithms to Post Quantum Cryptography (PQC) to the 2024 released public PQC algorithms.   This part is understood.  The majority of the world is changing to TLS V1.3 in readiness for the migration for Internet transactions, as the latest TLS V1.3 can easily accommodate the PQC migration - look at CloudFlare, AWS, Azure and Google.

All RSA and ECC based certificates by 2030 will be redundant - there are massive strategic attacks going on at the present time, which are increasing rapidly thanks to ChapGPT Model 40 LLMs and others designed to search vulnerable systems, and attack them on sight.   This is also driven by other state nation services, which you can understand are the likely attacks given their notoriety - without me spelling it out to you due to your background.

Second problem due to the Entrust CA problem, having issued 26,000 EV type certificates and lying about it before finally admitting the problem - were distrusted by the Certificate Authority (CA) and Browser Forum - mainly made up of Apple and Google.

They mandated the following:   Reduction in the lifetime of certificate expiry to 200 days by 15 March 2026 and rapidly reducing to 47 days by 2029 on 15 March 2029.   

Read original blog:  https://www.digicert.com/blog/tls-certificate-lifetimes-will-officially-reduce-to-47-days

https://www.digicert.com/blog/key-takeaways-from-the-entrust-incident

Both Crypto Agility is required by 2029 for CA/Browser Forum requirements  and PQC by 2030 means automation of certificates from external CA's is required for both regulatory compliance reasons, HIPAA, PCI DSS and ISO 27001:2022 Annexe 12 has already shifted to the stronger PQC migration.   Yes, many will say but we don't have to shift internal certificates to automation because we have our own Internal CA's and self generate our own certificates.   Where does the root of trust come from - in a lot of cases from an external CA, unless you have created your own SOC environment and security controls with your own HSMs etc.

In Australia they have the SOCI act which applies also to all critical infrastructure which ramp up and change annually progressively forcing stronger controls and risk management techniques to be applied.

Well, first of all PKI will no longer exist once the first quantum computer breaks RSA and ECC due to Shor's Algorithm - this is a well known fact.

So Public Key Infrastructure Key Management as we know it will be redundant, so will existing HSMs as they cannot deal with the new PQC algorithms.

So Hybrid HSMs are being created and certified.

Quantum Key Management (QKM) is the new normal.  

The other comment:  A lot of organisations still use the "spreadsheet", but others have migrated to ITSMs, or CMDB's. They have their own problems - manual practices, and inherent human error and configuration issues.

They cannot request certificates and neither can they implement certificates externally or internally or even wild cards or even apply to Kubernetes or other such technologies including SSH.

The only way to deal with the 47 day certificate expiration period is automation.

Remember those current PKI methods are used not only for confidentiality, integrity, non-repudiation and authentication purposes too - so all of this has to change.

So - you have two major problems the Certificate Authority / Browser Forum mandates and then on top of that PQC.

As I stated it will take 3-4 years for the majority of large organisations to discover, undertake risk management, progress to test and migrate to Crypto-Agility mode - due to performance hits on the use of various PQC algorithms and capabilities - back to dialogue with the vendors to change their equipment etc.

The Australian Government is offering incentives other nations are still asleep at the wheel - time is ticking by.

As I stated 2026 will be a big year in AI, data security, Quantum Computing and hybrid classical computers working in conjunction with Quantum Computing, it is already happening.

Ignore at their own peril, prepare, discover, test and transform, including education of organisations.

The connecting piece you are not getting is "Crypto-Agility" affects both PQC and Certificate Lifetime Management.

Regards

Caute_Cautim

[denbesten]

I do understand that PQC puts current encryption/hash algorithms and risk and that we need to prepare for refreshes in systems using them.  But that is a topic for another discussion as it is not the question the OP was posing. 

The part I am struggling to understand is with respect to SSL/TLS certificate management tools (the topic of this conversation), what do you recommend people do today?

[JoePete]

---

@AaronFaby wrote:

Now that SSL/TLS certificates will have shorter lifespans, managing all of the certs that are in use by an organization is going to be even more important. 

---

Just to throw out a contrarian view, does anyone else think the 47-day window is a bit overkill? To some extent, we're doing the same thing with web serving that we did with email (DKIM, SPF, DMARC, etc.) over the years - continually complicating the process in the name of "security," but in the end, we create availability issues, encouraging these critical services to be hosted/reliant on a handful of providers (because there are too many hoops to jump through). Should one of those providers experience an issue (hey, AWS?), the Internet grinds to a halt.

I'm happy to be educated/corrected on this, but off the top of my head, it is hard for me to think of an actual incident involving certificates that was about the weakness of the cryptography. More what comes to mind is that things like private keys were not stored securely. To analogize, this would be like requiring people to change the locks on their houses every two months because some people tend to misplace/lose their keys.

To the original question, however, I think ultimately this tips the scale to handing your web serving and other certificate-based resources over to a third party. This will increase cost and point of failure while also increasing the disconnect between businesses and the resources they depend. And to adjust my tinfoil hat slightly, I don't see this as a security objective, but more a marketing one. The harder we make it for people to run their own services, the more it boosts a handful of providers. 

[denbesten]

@JoePete wrote:

...does anyone else think the 47-day window is a bit overkill? ...

My initial reaction was similar, particularly given that my colleagues and I sign hundreds of certs per year for our webmasters.  Our collective cry was that a 12x increase in effort was not sustainable and that they should have just done a single reduction, to 6 months. 

What I have come to realize is that this really is that there is a long-term trend here and they really are just revealing three of their cards at once, instead of playing them one at a time:

• <=  2015       5 year max
• 2015 - 2018  3 year max
• 2018 - 2020  2 year max
• 2020 - 2026  1 year max

• 2026 - 2027  6 month max 
• 2027 - 2029  3 month max  
• 2029 +          1 month max

The irony to this entire thing is that we were happily giving Entrust lots of money every year until Entrust pissed in the pot.  And, it was their pissing that resulted in 47 days and kickstarted my company's ACME/Let's Encrypt adventure that already has reduced our future annual PKI spend by more than half.

Sure, there are security-geek benefits, such as reducing one's dependency on CRLs and shortening time-to-production for new encryption/hash algorithms, but nothing sells quite as easily as a permanent reduction in ongoing spend.

[Caute_cautim]

@denbesten @JoePete @AaronFaby 

I hear your pain, and I fully understand it.  I am going through the same pain where I am located, except most of New Zealand is asleep and a lot of security people have migrated to Australia where they can have a better life - if they like Sun, Sea, Snakes, Crocodiles, Stinging Wasps and poisonous spiders they have it all - gone through all that previously.

There are many areas which are misunderstood such as Developers not understanding how to use PKI root structures for protecting Kubernetes containers etc due to the complexity when really they just want the job done especially when they are attempting to get CI/CD pipelines up and running etc.  

I am coming across organisations who use ITSM's such as ServiceNow, or Spreadsheets, or CMDBs, but the entire processes are manual - mistakes occur, misconfiguration s occur, and often the expiration date is left to one or two people who actually understand certificates.  Whether they are used within SSH server farms or proxies, firewalls or IoT devices etc etc.

I agree that many will think about moving to cloud providers, but are they any better than organisations, looks at Microsoft outages, or AWS massive outages and we become totally dependent upon them all.

All of which have their weaknesses, either the certificate database is a flat file, and you need authorisations. scripts to make certificate requests and then you need scripts and APIs and additional integrations with Hashicorp Vault or Jenkins or even Kong for applications.  It comes in all shapes and measures.  

There are many providers out there who can provide integrations. semi-automate the certificate lifecycle management process, which historically we have left to the few and to those who actually understand it.  Who swallowed the NIST three volume bible on certificate management etc.

Current HSMs will be redundant in the next four years, they are costly bricks but essential in many cases, whether built into an IoMT device or ICS device etc - which points back to the vendors and their capabilities.

There are many providers, I have done some research on a number, but at the end of the day it is down to the organisation:

1) On Premises, do it yourself; 2) Build it yourself' 3) Manage it yourself; 4) Use a SaaS service and manage it yourself; 5) SaaS service and get them to manage it for you etc.  

There is a lot more to this:  Risk Management; Assessment of current environment, Design for automation; Proof of Concept; design workflows for automation, test and test and keep testing - start small and grow in confidence, get the bugs out of the system.  I suggest using an ITSM or CMDB integrate it, but ensure you have full visibility, able to handle incidents, notifications, and audit trails and reports are really important.

Most of these systems are based on the number of certificates to handle - the greater the number, the less the cost annually.

This is only the start of a journey, then think about Crypto-Agility with PQC, migration from Public Key Infrastructure and Hybrid systems towards Quantum Key Management - sorry folks it is happening like it or not.

Blockchain security is busted, not because of the cryptographic algorithms,. but the entire processes around including who can you trust.

Humans are inherently insecure, we make mistakes, the impacts are becoming bigger.

If you reach out I am happy to share some of my findings; but not on a public basis.

A lot of development, experience needs to be built up and humans only really learn through pain, rather than someone putting it on a plate for them.

Compliance and regulations are progressing and chasing us all hard.

Regards

Caute_Cautim

[Caute_cautim]

@denbesten Good luck with your Lets Encrypt journey.  I looked them up last night, and saw that they have done some creative work towards automation, via various scripts and approaches.  Including some Github ideas for Azure including:  https://github.com/AddEleven/lets-encrypti-azure-automation

Including some links on Linkedin.com as well too. 

There is a some fascinating work going on towards overcoming our current challenges - but as usual test, trust but verify at all times.

Regards

Caute_Cautim