Hybrid certificate lifecycle manager for midmarket IT

I'm evaluating CLM platforms and narrowing down our shortlist. Environment is hybrid but mostly on-prem about a dozen TLS certs deployed across ~100 places (F5, Fortinet, Azure Key Vault, IIS, etc). Ideally CA agnostic because I hate the idea of paying $200+ per cert in 2026. Today the rotation process is manual. I've gotten quotes from 5k for new players like Certkit and 100k+ for the legacy platforms of Cyberark and Keyfactor command. We probably could make it work with a bunch of different opensource tools but we have the budget and I don't want to maintain that long term. Currently evaluating: Keyfactor Command - CA agnostic, broad integrations, code signing. Feels like the most mature platform. How's the deployment and ongoing management? The sales process has been annoying with several meetings just to get a demo and quote tons of unnecessary line items inflating cost. CyberArk (Venafi) - Well reviewed, but curious how the acquisition will play out. Is the product still getting investment or is it getting absorbed into the CyberArk ecosystem in a bad way? Sectigo SCM - Quoted us $45K for 200 certs, seems decent and modern but really not CA agnostic as they don't work with Google PKI or lets encrypt. Already dropped CertKit (to small of a company even though this seems like a good product), and Akeyless(doesn't integrate with very many DNS providers). Any gotchas, hidden costs, or things you wish you knew before signing? I don't want to choose one of the bloated legacy players but they seem to check most of the boxes. Are there any other new players I should check out? Coming from a cloud native company I miss AWS Certificate Manager :/

Hey everyone, looking for advice on the best way to fully automate SSL renewals for our ScreenConnect server. Right now our setup is: ScreenConnect hosted on a Windows Server in AWS We purchase a new SSL certificate manually every year We manually install and bind the cert ourselves We want to get rid of the yearly manual process and have renewals happen automatically with as little hands-on work as possible. I am looking for recommendations that fit this type of environment, and ideally step-by-step guidance on how to set it up. A few specific questions: What is the best approach for ScreenConnect on Windows in AWS? Should we be using Let’s Encrypt, AWS Certificate Manager, ACME, or something else? What tools or scripts are people using to automatically renew and re-bind the cert for ScreenConnect? Is there a reliable way to handle the binding without breaking access during renewal? Are there any gotchas specific to ScreenConnect on Windows Server? If anyone has a similar setup running successfully, I would really appreciate a practical walkthrough of how you built it. Thanks.

We've been tasked with figuring out a way to automate our SSL certificate handling. Yes, I know we're at least 10 years late. However due to reasons I'll detail below, I don't believe any sane solution really exists which fits our requirements. Our environment ~700 servers, ~50/50 mix of Windows / Linux A number of different appliances (firewalls, load balancers etc) ~150 different domains Servers don't have outbound internet connectivity nginx, apache, IIS, docker containers, custom in-house software, 3rd party software We also use Azure and GCP and have certificates in different managed services there We require Extended Validation due to some customer agreements, meaning Let's encrypt is out of the question and we need to turn to commercial service providers with ACME support So far we have managed certificate renewals manually. Yes, it's dumb and takes time. Given the tightening certificate validity times we're now looking to switch to ACME based automation. I've been driving myself insane thinking about this for the last few weeks. The main issue we face is that we can't just setup certbot / any other ACME client on the servers using the certificates themselves, for multiple reasons: A large amount of our services run behind load balancers and the load balancers perform HTTP -> HTTPS redirects with no way to configure exceptions. This means our servers can't utilize HTTP-01 ACME challenge. Our servers have no outbound internet access, meaning we can't access our DNS provider's API for DNS-01 challenge for example. Even if we could, we have ~150 domains and our DNS provider doesn't provide per-zone permission management. Meaning all of our servers would have DNS edit access to all of our domains, which is a recipe for disaster in case any of them get breached. So client ACME + DNS-01 is out of the question as well. Given that our servers can't utilize HTTP-01 or DNS-01 ACME challenges, the only viable option seems to be to set up a centralized certificate management server which loops through all of our certificates and re-enrolls them with ACME + DNS-01 challenge. This way we can solve certificate acquisition. If we go the route of a centralized certificate management server we then need to figure out a way to distribute the certificates to the clients. One possibility would be to use a push-based approach with ansible for example. However we don't really have infrastructure for that. All of our servers don't have centralized user management in place and creating local users for SSH / WinRM connections is quite the task, given the user accounts permissions would have to be tightened. We also run into the issue that especially on Linux we use such different distributions from different times that there isn't a single ansible release which would work with the different python versions across our server fleet. Plus having a push-based approach would make the certificate management server a very critical piece of infrastructure, if an attacker got hold of it they could get local access to all of our servers easily via it. So a push-based approach isn't preferable. If we look at pull-based distribution mechanisms then we require server-specific authentication, since we want to limit the scope of a possible breach to as few certificates as possible. So every server should only have access to the certificates they really need. For this permission model probably the best suited choice would be to use SFTP. It's supported natively by both Linux and Windows and allows keypair authentication. This creates some annoying workflows of "create a user-account per client server on the certificate management server with accompanying chroot jail + permission shenanigans" but that's doable with Ansible for example. In this case I imagine we'd symlink the necessary certificate files to the chrooted server-specific SFTP directories and clients would poll the certificate management server for new certificates via cron jobs / scheduled tasks. Ok, this seems doable albeit annoying. Then we come to handling the client side automation. Ok, let's imagine we have the cronjobs / scheduled tasks polling for new certificates from the certificate management server. We'd also need accompanying scripts for handling service restarts for the services utilizing these scripts. Maybe the poller script should invoke the service restart scripts when it detects that a new version of any of the certificate files is present on the cert mgmt server and downloads them. Then we come to the issue that some servers may have multiple certificates and/or multiple services utilizing these certificates. One approach would be to have a configuration file with a mapping table for "certificate x is used by services y and z, certificates n and m are used by service i etc". However that sounds awful, maintaining such mapping tables does not spark joy. The alternative way of handling this would be to just say "fuck it, when ANY certificate has changed, just run ALL of the service reload scripts". That way we would not need any cert -> service mapping tables but it'd in some cases lead to unnecessary service downtime for some specific services where reloading them causes application downtime. Maybe that's an acceptable outcome, not sure yet. But the biggest problem I see with this approach is actually managing the client-side automation scripts. As described earlier, we can't really rely on Ansible to deploy these scripts to target hosts due to python version mismatches across our fleet. But I'd still want some sort of a centralized way to deploy new versions of the client scripts across our fleet, since it's not particularly unimaginable that some edge cases will pop up every now and then requiring us to deploy new version of some IIS reload script for example across our fleet. It'd also be nice to have a single source of truth telling us where exactly have different service reload scripts been deployed to (just relying on documentation for this will result in bad times). So to combat that problem... More SFTP polling? This is where this whole thing starts to feel way too hacky. The best answer to that problem that I've come up with is to also host the client-side scripts on the certificate server and deploy them to client via the same symlink + client-side poller script setup. Thus we can see on the certificate server what servers use what service reload scripts and updating them en masse is easy. But this also feels like something we really should not do.. Initially I thought we should just save the certificates to a predefined location like /etc/cert-deploy/ and configure all services to read their certificates from there, rather than deploying the services to custom locations on all servers. However I now realize that brings permission / ownership problems. How does the poller script know to which user the certificates should be chowned to? It doesn't. So either we'd require local "ssl-access" groups to which we'd attempt to add all sorts of generic www-data, apache, nginx etc accounts and chgrp the cert files to that group, or the service reload scripts should re-copy the certs to another location and chown them with user account that they know the certs will be used by. Or another mapping table for the poller script. Yay, more brittle complexity regardless of choice. At this point if we go with an approach such as this one, I'd also want to have some observability into the whole thing. Some nice UI showing when have the clients last polled their certificates. "Oh, this server hasn't polled their certificates for 10 days, what's up with that?" etc. Parsing that information from sftp logs and displaying on some web server is of course doable but once again one starts to ask themselves "are we out of our minds?". I even went as far as I started drafting up a Python webserver which would replace the whole sftp-based approach. Instead clients would send requests to the application, providing a unique per-client authentication token which must match the client token stored in a database. Then the application would allow the client to download the certificates and service reload scripts via it. It'd allow showing client connection statistic more easily etc. However my coworker thankfully managed to convince me that this is a really bad idea both from a maintainability and auditing POV. So, to sum it all up.. How should this problem actually be tackled? I'm at a loss. All solutions I can come up with seem hacky at best and straight up horrible at worst. I can't imagine we're the only organization battling with these woes, so how have others in a similar boat overcome these problems? Read more

Hi, With next year's certificate lifetimes due to decrease ( https://www.digicert.com/blog/tls-certificate-lifetimes-will-officially-reduce-to-47-days ), does anyone have hands on experience and recommendations for ACME in a medium sized corporate environment? We order around 200 public SSL certs annually and have a similar number of internal certificates. We have a range of services where these certificates are applied - NetScalers, Azure instances, websites, Windows servers and the odd Linux appliance\server. What we're after is a solution which can manage the entire certificate lifecycle from issuance to monitoring, reporting and renewal. In addition, we'd likely need a partner to help with the configuration and deployment of the ACME solution. Does anyone have any recommendations? Thanks

Hello, At my work we currently use one wildcard certificate for everything, we buy a new one every year and manually replace it on all servers. I started started looking into automated certificate management using Let's Encrypt which works great. My issue is that this company basically does not want port 80 open at all, not even on private networks. Let's say we have two servers, one nginx proxy and one IIS-webserver. The nginx proxy uses SSL-bridging, so the certificate needs to be on both the proxy and the IIS-webserver. Is there an easy way to handle this? Sure i could just automate the copying of the certificate from the proxy to the webserver. But then adding it to the certificate store and editing IIS-bindings comes into place. Sure, it could be scripted via powershell but it feels like murphy's law waiting to happen. Am i overthinking all this, is there another solution? All advice is welcome. Read more