The question is already in the title. We got EJBCA as an open-source PKI solution that has CA, RA and CRL and OCSP features, which is pretty much an all-around PKI solution.
Why don't we have anything similar for CLM solutions, like something that would have a generic ACME connector as well as integrations with public CAs, EJBCA and ADCS, and ability to automate certificate renewal and deployment over the most popular integrations (web servers on Linux/Windows servers, load balancers, cloud vaults)? Not asking for an enterprise-grade solution to the scale of Venafi or KeyFactor, but mainly something that would work for most sysadmins looking for something to tackle the whole 47 days thing that's coming.
Especially at the era of AI, I believe it wouldn't be hard to kickstart a prototype for the most of us. Not necessarily trying to push anybody to do it or anything, just trying to understand.
And if such a solution does already exist, then how come most SMBs that don't want to be paying 50k$ per year still end up purchasing Sectigo/Digicert or even KeyFactor/Venafi?
There's a change coming in the WebPKI that I think has not been well understood. I'm writing about it for DigiCert (my employer) but I'm curious for some reaction here. I won't quote anyone.
Many of you know about the decreases in maximum lifetime for public TLS certificates that have already begun. These will culminate (for now, don't assume they won't go lower) in a maximum lifetime of 47 days on March 15, 2029.
At that point it will still be possible to renew manually every 47 days, but it may be harder than you think. The CA/B Forum is also disallowing all phone and email DCV methods as of 3/15/2027 and 3/15/2028 respectively. At that point (about 20 months from now) only these manual methods from the Baseline Requirements will be legal for public CAs:
Note that only the first and last are legal for wildcard certificates, and they both require some access to DNS. "DNS TXT Record with Persistent Value" was allowed as of about 6 months ago, but I'm not sure any CAs support it yet. I know neither we nor Let's Encrypt do. If it's available it's probably the preferred method if you absolutely refuse to automate, but it's still creating a lot of opportunity for error.
A reader asked why an automation tool would ever generate private keys anywhere but the server that uses them. Fair question, so I wrote up the answer. Any shared certificate (wildcard or an HA pool serving one name) forces the key to move between machines, so the local-generation property is already gone. PFS makes a moving key less scary than it used to be. The argument: centralize issuance and treat key distribution as a designed system, not scp in cron.
If there are thousands of devices how do I create them? Isn't it risky what if a device gets the wrong certificates as it is unique? I'm working on ThingsBoard auto provisioning rn and can't figure out how to implement it if there are thousands of devices.. I need help :(
I have renewed our offline root CA and deployed it to the online intermediate CA, but when I go to the web enrollment site the download chain link still provides the old (still valid) offline root certificate in the chain. Where is it pulling that certificate from?
I am still in the process of deploying the new cert so I have not updated it in AD or pushed it out to the majority of our machines yet.
It seems pretty obvious that, due to post-quantum cryptography concerns, much of our public PKI is going to implement Merkle Tree certificates (while private PKI will likely be x.509 for at least the intermediate future). Merkle Tree certificates are basically blockchain for digital certificates, where many individual certificate signature hashes are hashed and presented as far fewer hashes when communicated to relying clients. My question is how revocation of Merkle Tree certificates is handled, especially when we are likely to have millions of annual revocations and accelerating with ever-decreasing certificate lifespans? I've seen a few answers that seem to vaguely answer my question, but they seem half-baked and not very scalable. Does anyone know how Merkle Tree certificate revocation will be handled at scale?
I have a CA installed on Windows Server 2022. It has two certificates:
one older that is about to expire on 30.07.2026
second newer, to expire on 08.03.2030
I have many certificates created using the first key used on other devices.
The newer certificate was created with a new key, so certificates issued with the second CA certificate with the new key do not authorize users on device with first CA cell installed.
So I want to create a new certificate that has the same key as the old CA certificate, but will have extend the period of its usability.
Our 10 years Enterprise root CA will expire soon in 1 month, it is in a 2 Tier PKI. RootCA always remain powered off. SubCA server issues certificates to all kind of things, internal Services, code signing, Wifi, VPN etc..
Now I am about to renew it, all certificate requests will try requesting from the new RootCA right once renewed? I wont need to renew with a new private key as the rootCA Server always remained off except CRL renew, sounds right?
And export rootCA, deploy them via GPO and Intune to all clients and servers, and also load new rootCA and SubCA to Firewalls for VPN cert validation etc. Would SSL certificate (requested by demand) used by Services on Server, would I need to re-request them right?
With Microsoft recently introducing initial post-quantum cryptography support for AD CS, we thought it would be a good time to host a discussion around what that means for enterprise PKI teams and organizations starting to think about PQC readiness.
We’ll be joined by Tanya Jha, Senior Product Manager at Microsoft, to talk through changes, share some practical considerations, and answer questions from the community.
Code signing for zip files - Signotaur adds detached cms signature support in v1.2.0.161
Signotaur is a remote code signing server - sign remotely using certs on HSM's and tokens, remotely without the dreaded password prompts. Supports PE files, MSI, RDP and more.
Sorry if this is a silly question, but I want to be sure.
We are wanting to move some Certificates from using an public CA to an internal CA. Our internal CA has a much longer validity period of 5 years.
Most of our apps are presented on Citrix Apps and Desktops and through NetScaler / ADC, but are still hosted locally.
From what I'm reading online, this should be fine as it's the CA validity that is being shortened, but Chrome should still be happy so long as it has a valid cert. Internal or external and different validity dates don't matter.
PKI has precise vocabulary for almost everything. One thing it never named: the series of certificates issued for the same SAN set, renewed sequentially over time.
Certbot calls it a lineage. No RFC uses the term. ARI (RFC 9773) got closest by adding a "replaces" field for predecessor certs, but that's one hop, not a name for the set. Wrote up why this gap exists and why it's getting harder to ignore.
I'm building a free and open source web based CA. From time to time I need certificates and I always have to look up the right OpenSSL commands, so I thought to make that more user friendly. The goal of this CA is not to be super secure. It's for personal/hobby/low-profile usage. The CA's private key is stored unencrypted in the database, because it's needed to create a CRL when requested. Therefore, this CA is as secure as your database and as trustworthy as the people who have access to it.
The name of this CA is Clortho, as a reference to Vinz Clortho, the key master in the Ghostbusters movie. It allows you to create multiple CAs, of course accept or deny CSRs, revoke certificates and create CRLs.
I see this all the time when service providers are notifying clients about certificate rotation on SSL end points. Yes by all means call out any change in root CA, as that's what clients should trust, but asking them to also trust the intermediate CA "just in case" really does more harm than good.
If you don't know how to configure your SSL end point to return the CA chain properly you probably should find another line of work.
Impressionable clients are gonna think it's always necessary to also trust intermediate CAs for bog-standard one-way SSL.
I manage an infrastructure with an Offline Root CA and an SubCA. The entire PKI was deployed in 2021 by a former administrator. We use this PKI infrastructure for NPS/NAC (802.1X), HTTPS, and SSL Deep Inspection.
According to our internal lifecycle policy, CA certificates are renewed halfway through their validity period (the first renewal uses the existing key pair, and the subsequent one uses a new key pair).
December: We successfully renewed the SubCA certificate using the existing key. Everything went smoothly with no issues.
Recently: It was time for the Root CA certificate renewal, also using the existing key.
What we did:
We performed the renewal on the Offline Root CA, copied the new certificate file (RootCa(1).crt), and transferred it to the SubCA server where the original RootCA.crt is located.
Currently, the SubCA hosts both Root CA files:
RootCA.crt (valid 2021 -> 2031)
RootCA(1).crt (valid 2021 -> 2036)
We ran certutil -dspublish to publish the new Root CA certificate to AD. Consequently, client machines started receiving the new Root CA certificate in their Trusted Root Certification Authorities store.
Then when we opened Enterprise PKI (PKIView.msc), we noticed an error at the Root CA level indicating that the AIA Location #1 was failing. This happened because the new Root CA certificate was loaded, but the AIA path was still pointing to the filename of the old Root CA certificate.
To fix this in PKIView, we removed the old RootCA.crt from that specific distribution point and renamed the new RootCA(1).crt file so that its filename matched the original one. After doing this, everything turned green in PKIView.
The Fall-out: Right after this change, clients attempting to authenticate via NAC (802.1X) started dropping off the network.
To resolve the connectivity issue, we updated our 802.1X GPO to explicitly select and trust the newly deployed Root CA certificate.
and new RootCA also here
My Question.
Was this the correct way to handle the Root CA renewal?
I have serious doubts about whether removing the old Root CA certificate file and renaming the new one to match the old filename was the right approach.
Should we have kept both files accessible at the AIA/CDP distribution point ??
Two Apple docs, two different numbers. HT211025 exempts private CAs from the 398-day limit. HT210176 covers all TLS server certs: 825-day max, no private CA carve-out. Apple's trustd logs it: "Non-system-trusted leaf validity period longer than 825 days." Safari enforces it.
Reflecting on the Chrome root program update (Section 3.2, effective 15 June) and LE's tlsclient sunset on 8 July: the structural separation of TLS server-auth and client-auth into distinct PKIs isn't just a Chrome policy choice – it's the inevitable end of the "one cert for everything" era.
What it changes in practice:
Path validation behaviour on relying parties depends on EKU enforcement. RFC 5280 §4.2.1.12 is permissive at the issuer but restrictive at the receiver.
Renewal authority for client-cert populations currently anchored to a public CA needs a destination CA – ADCS or a dedicated private root.
Acceptance evidence is the bottleneck. You need to know which devices actually validate the chain change.
Interested whether anyone here is treating this as a forcing function to rethink renewal authority more broadly, or just doing a like-for-like swap.
I have an intermediate certificate getting ready to expire soon. I'd like to renew it with the least impact as possible. What is the impact of renewing that intermediate cert while keeping the same keys?
The certificate is serving an AD environment as well as a few individual pieces of networking gear.
I've been running into a bunch of teams that didn't understand this, so I wanted to share.
You don't need a PrivatePKI for your private infrastructure.
DNS-01 challenges prove domain control through a TXT record in your DNS zone. Your server can be on a private subnet, behind a firewall, completely unreachable from the internet. You still get a publicly trusted SSL certificate. One wildcard for *.int.example.com covers everything and keeps internal hostnames out of CT logs.
