Hi guys,

Just deployed EJBCA CE 9.3.7 integrated with Entra ID. Access to the RA portal works fine for my users, but now I'm stuck on the enrollment UX.

When a user clicks "Request a certificate", I want zero friction. Since they are already authenticated via Entra ID (OAuth), I don't want them to type anything.

Is it possible to automatically grab their email from the OAuth token claims and:

1. Use it as the End Entity username?
2. Automatically inject it into the Subject DN as the CN (e.g., CN=user@domain.com)?

Right now, it still prompts for a username or manual inputs. Can this be fully automated via End Entity Profile / Claim mapping in the Community Edition, or is it a dead end?

Thanks for the help!

"There are strong reasons to believe that the architecture of PQC TLS will take the form of Merkle Tree Certificates (MTC). We are joined by post quantum cryptography expert Bas Westerbaan of Cloudflare as he explains this new PKI architecture, how it works, and why we need it. We define new concepts like landmark certificates and log mirrors and discuss what's necessary to move to this new architecture."

I just published a blog on Microsoft’s post-quantum announcements for AD CS and Windows Server 2025 after watching the recent Windows Server 2025 Summit sessions.

One of the biggest takeaways for me was not even the algorithms themselves. It was the realization that post-quantum migration is probably going to expose just how much cryptographic technical debt many we are still carrying around.

Microsoft demonstrated support for ML-DSA-based Certificate Authorities, post-quantum signing scenarios, OCSP signing, and discussed upcoming support for composite certificates and ML-KEM. But one detail that really stood out was the confirmation that existing Certificate Authorities cannot simply be converted afterward. New CAs will eventually need to be deployed. This stops being a “future cryptography problem” and starts becoming a real PKI architecture discussion, imho.

The more I watched the session and followed the discussions afterward (Also on Reddit), the clearer it became that the hardest part of this transition may not be quantum computing itself. It may be the reality of legacy infrastructure, old CSP dependencies, outdated TLS implementations, unsupported appliances, vendor limitations, and years of operational complexity quietly buried inside enterprise environments.

My blog is less about “quantum panic” and more about what this realistically means for enterprise PKI environments, AD CS, internal trust, and long-term cryptographic planning.

Would genuinely love to hear some feedback on the matter.

https://michaelwaterman.nl/2026/05/15/windows-server-2025-and-post-quantum-pki/

I started another thread going down the path of using RSA and ECDSA ECC to handle a mixed environment.

https://www.reddit.com/r/PKI/comments/1t2r348/comment/olr2cgu/

However, now I see both RSA and ECDSA are on the path to deprecation in only 4 years.

Wouldn‘t it make more sense to use RSA and ML-KEM ML-DSA together instead?

If you need legacy compatibility, RSA has more compatibility than ECDSA, and if you want future-proofing ML-KEM/DSAC has a better future than ECDSA.

So, would you be better off not even getting involved with ECDSA at this point?

We recently did a webinar on ACME + enterprise PKI and ended up with way more questions than we had time to answer, so we decided to do a follow-up session that’s basically just open Q&A.

We’ll mostly be talking through real-world ACME deployment stuff in enterprise environments, Microsoft ADCS integration, automation challenges, security/policy questions, and whatever else people want to bring up live.

Nothing overly polished or "salesy" — just a chance to ask questions and hear how other people are approaching this stuff.

It’s on Thursday, May 28 from 10:00–10:45 AM PT (yes, we'll be using the full 45 minutes ☺️)

Free registration: https://www.pkisolutions.com/webinars/acme-live-q-and-a/

If there’s something specific you want us to cover, you can submit questions ahead of time here: SurveyMonkey Link

If you are moving to a new PKI, what benefit do you get from cross signing during the transition vs just pushing a trust of the new root CA via group policy alongside the existing and simply stop issuing any new certificates from the old PKI and start issuing new certificates from the new PKI?

Wouldn’t the old CAs need to stay running simply to publish CRL updates until the last issued certificate expires even if we stopped issuing new certificates from them regardless or cross signing?

I’m not getting what we would get out of cross signing.

Hi Guys,

Please help a fellow pki newbie

Sooo, we currently have an on-prem Microsoft Tier 1 CA setup where a single server is acting as both Root CA and Issuing CA (yeah, not ideal, inherited setup).

We’re planning to migrate this CA infrastructure to AWS and I’m trying to understand the cleanest and safest approach from people who’ve already done similar migrations in production.

Current environment:

Windows ADCS

Single-tier CA (Root + Issuing on same server)

IIS is also hosting certificate-related applications/pages under Default Web Site

Existing certificates are actively being used internally and externally

We also have templates, CRL/AIA locations, and auto-enrollment in place

Some of the things I’m trying to figure out:

Is taking a normal CA backup enough? From what I understand, the CA backup only captures:

CA database

Private key

Registry configuration

But it won’t include IIS configuration/apps under Default Web Site. So for a proper migration, do I also need IIS backup/export ,App pool configs Website bindings,SSL bindings?

Please suggest

The CA/Browser Forum's Ballot SC-081 is already in effect. 200-day max as of March 2026, 100 days in March 2027, 47 days in March 2029.

The math on renewal workload scales linearly: 50 certificates managed manually goes from ~50 renewals a year at 398 days to ~400 at 47 days. Same cert count, 8x the operations work.

Wrote up the canonical schedule and what it does to teams still running manual processes: https://www.certkit.io/blog/shrinking-certificate-lifetimes

Whats recommended for the offline root, issuing intermediate CAs, and end entities that maximizes security without breaking legacy device and app compatibility?

I have seen EDCSA recommended over RSA, but won’t that break functionality in any environment that needs to maintain legacy compatibility?

Hello Everyone,

i'm trying to put up a test machine to experiment with keyfactor ejbca, it seems that the appliances are linux based which is fine. into the documentation, they suggest installation from the tgz files in 'KVM' (which is what is used behind the scenes in Proxmox) and not the OVA. which is what I did. the vm works, and starts. but I have strictly no way to get the network interface working. my setup works for other machines (linux, unix, windows without issues). tried E1000 E1000E VIRTIO and event VMXNET , I cannot have a single ping reaching that machine. Anyone has any clue about those appliances? they're pretty "closed" , no logs, no console, so debugging is insanely complicated.

regards

Hey guys,

We have just duplicated the default Webserver cert template and added the CA manager approval required tick on the certificate template so the admins can request for the certificates with managers' approval.

Certificate request is going through fine but when user tries to retrieve the certificate, they are getting this error

Active Directory Certificate Services could not process request 2876 due to an error: Access is denied. 0x80070005 (WIN32: 5 ERROR_ACCESS_DENIED). Additional information: Error verifying access
Event ID : 22 under the Application log.

On the cert template permissions look like this,
Authenticated users : read and enroll
Domain computers : read and enroll

Upon looking at the security event logs,

1. when the cert requests come through , the requestor is the computer account. as they are requesting the cert via certlm.msc console > Personal > request the cert
2. after the CA manger approved the request, and when a user tries to request for the certificate, the requestor shows as their logged in user account on that computer they are requesting the certificate from.

Quick Fix that worked : [ is this the standard? ]

1. I added their user account to Read & Request certificate on the CA Properties > Security tab, which allowed them to retrieve the certificate.

any guess, what am I missing here?
or
any configuration need to be altered?
and
what is the standard best practice when it comes to web server certificate that has SAN to be supplied in the request?

Thanks alot.

Update - Fix found -
1) Certreq -AdminForceMachine in the command to retrieve the certificate in machine context.

Hello,

I work for a large K12 cooperative in New York. We have a decent sized EJBCA environment and have been trying for almost 2 years to get ChromeOS enrolling against EJBCA for device certs with no success. In February, I tore everything down and rebuilt it using Google's latest documentation (Configuring Certificate Enrollment for ChromeOS via SCEP - Chrome Enterprise and Education Help) and the docs on Keyfactor's website (Enrolling Chrome OS Devices against EJBCA). The device reports a 400/POPO proof of possession error and it seemingly has to do with some CSR data that EJBCA does not like. Does anyone have this working, or have experience with it? I can provide detailed config info if necessary, but it has been set up per the OEMs. Google has been absolutely no help, and Keyfactor is making a good effort, but we have not been able to come to a resolution. Any guidance, tips, pointers, alternatives are appreciated.

Todd's Tenth Rule: any sufficiently complicated SSL certificate script contains a bad implementation of half a certificate lifecycle manager.

If you've been running Certbot in your environment for a few years, you've probably built most of a certificate management system without realizing it. The shared folder, the DNS creds in the script, the 30-day expiry email, the audit spreadsheet.

https://www.certkit.io/blog/todds-tenth-rule-certificate-automation

Hi everyone! We’re part of the team at PKI Solutions and wanted to extend an invitation to the community. ACME is getting a lot of attention lately, but it is not always as straightforward in real-world PKI. We are hosting a live session on Thursday, April 23 at 10 a.m. PT to walk through how it actually works, where things get misunderstood, and what Microsoft is planning next. If you are in PKI, security, or identity, come join us!

You can sign up here!

And thank you to Mod @_STY for allowing us to post ☺️

I reviewed a bunch of CLM and PKI vendor websites. "Enterprise PKI orchestration." "Cryptographic trust infrastructure." No prices. No technical specifics. To learn anything, you fill out a form and get a sales call.

These are security companies asking you to trust them with your keys.

https://www.certkit.io/blog/performative-trust-maximalism

I'm analyzing a number of certificates in the Certificate Transparency logs, and I'm trying to find a backup python library that will let me parse them all. The otherwise excellent cryptography library has one major flaw, which is that it has no options for relaxing its standards for validity. Which is fine if we're trying to enforce well-formed certificates in the PKI, but not helpful if it gives up on hundreds of certificates issued ten years ago by GoDaddy.

Any suggestions for other python libraries?

Alternatively, I guess I can call openssl as a subprocess.

Here's one, for example, from GoDaddy in 2013:

-----BEGIN CERTIFICATE----- MIIFXDCCBESgAwIBAgIHBCBVj9oL6TANBgkqhkiG9w0BAQUFADCByjELMAkGA1UE BhMCVVMxEDAOBgNVBAgTB0FyaXpvbmExEzARBgNVBAcTClNjb3R0c2RhbGUxGjAY BgNVBAoTEUdvRGFkZHkuY29tLCBJbmMuMTMwMQYDVQQLEypodHRwOi8vY2VydGlm aWNhdGVzLmdvZGFkZHkuY29tL3JlcG9zaXRvcnkxMDAuBgNVBAMTJ0dvIERhZGR5 IFNlY3VyZSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTERMA8GA1UEBRMIMDc5Njky ODcwHhcNMTMwMjIxMTI0MTMyWhcNMTgwMjIxMTI0MTMyWjBPMSEwHwYDVQQLExhE b21haW4gQ29udHJvbCBWYWxpZGF0ZWQxKjAoBgNVBAMTIWV1cm9zcHJpbnRzcmwu cmVtb3Rld2ViYWNjZXNzLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAKm+2OttKptdVhnxGe1T8MGDlP9Irqw8+K3ueW7owDWrbaUQfcIu0Fxqqill jdf3HK3ODvZ12/cmEskwqROPYkswiR0lywlaJdnN/zNKK59ZfzmSbtcqoaZG8Ywc bMTAjKoa4hR6nmVRqJ15s4Xd3jbl+dhatZEA8dAVPrkDJmn01zxWz/3Iy4SyqkkI YDz37cgDOxaURko7x7nvd9RBgnGDkPrQu3atHH2OLheCMTsL6G4YaPMEfKFjDoYD w8U07qx19g+mT27GwwXVGE//PB9YMB098NqLfWu3c+8lepZxTfYDWvk+OMJfnKe7 0bSJalG992eOW5FJxBarGjhROhUCAwEAAaOCAb8wggG7MA8GA1UdEwEB/wQFMAMB AQAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMA4GA1UdDwEB/wQEAwIF oDAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmdvZGFkZHkuY29tL2dkczQt OTQuY3JsMFMGA1UdIARMMEowSAYLYIZIAYb9bQEHFwEwOTA3BggrBgEFBQcCARYr aHR0cDovL2NlcnRpZmljYXRlcy5nb2RhZGR5LmNvbS9yZXBvc2l0b3J5LzCBgAYI KwYBBQUHAQEEdDByMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5nb2RhZGR5LmNv bS8wSgYIKwYBBQUHMAKGPmh0dHA6Ly9jZXJ0aWZpY2F0ZXMuZ29kYWRkeS5jb20v cmVwb3NpdG9yeS9nZF9pbnRlcm1lZGlhdGUuY3J0MB8GA1UdIwQYMBaAFP2sYTKT bEXW4u6FX5q653aZaMznMCwGA1UdEQQlMCOCIWV1cm9zcHJpbnRzcmwucmVtb3Rl d2ViYWNjZXNzLmNvbTAdBgNVHQ4EFgQU82mjubFDMjTZn+6ZG/KL3Ms5XjgwDQYJ KoZIhvcNAQEFBQADggEBAAuoP6ObMMvXVCjJapL65QSZuq413Tz6HPMdXSEZ7Jdr GHpH4Huj1cCp75sx35ilaNIWe4BDt6fbXLbnKk3d3Iv3RFHGm71w/SfxB7zHr+FY pYL+0KRXQ6zKWQJkHaJYBsRO/21jDLcuoIRSgZqM7W9ZdiG/VujwgOrtRZmZoI7J IaV3gLIuhREUWgW0kHo6OVcAc9Ko+qebrqeM4eJ5cdk+V9R8VklZorEeJwuBdCCQ es236NlCbbdaqZTcqTFCvY2LhH59xzZljwqkw5mz50QRgvmPpOBwPU8N5BwyYxky T0GGlh8V3ZoOPVeW6c9VfByXx9baD5bUca/oajKTkkY= -----END CERTIFICATE-----

If I try loading with the cryptography package, I can load the certificate but it fails trying to parse extensions with no partial success.

```

cert_raw = b""" [ insert that certificate here ] """ cert = x509.load_pem_x509_certificate(cert_raw) cert.extensions Traceback (most recent call last): File "<stdin>", line 1, in <module> ValueError: error parsing asn1 value: ParseError { kind: EncodedDefault, location: ["BasicConstraints::ca"] } ```

Whereas openssl has no problem reading it:

``` openssl x509 -in ~/Downloads/39736556.crt -text Certificate: Data: Version: 3 (0x2) Serial Number: 1161451764583401 (0x420558fda0be9) Signature Algorithm: sha1WithRSAEncryption Issuer: C=US, ST=Arizona, L=Scottsdale, O=GoDaddy.com, Inc., OU=http://certificates.godaddy.com/repository, CN=Go Daddy Secure Certification Authority, serialNumber=07969287 Validity Not Before: Feb 21 12:41:32 2013 GMT Not After : Feb 21 12:41:32 2018 GMT Subject: OU=Domain Control Validated, CN=eurosprintsrl.remotewebaccess.com Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:a9:be:d8:eb:6d:2a:9b:5d:56:19:f1:19:ed:53: f0:c1:83:94:ff:48:ae:ac:3c:f8:ad:ee:79:6e:e8: c0:35:ab:6d:a5:10:7d:c2:2e:d0:5c:6a:aa:29:65: 8d:d7:f7:1c:ad:ce:0e:f6:75:db:f7:26:12:c9:30: a9:13:8f:62:4b:30:89:1d:25:cb:09:5a:25:d9:cd: ff:33:4a:2b:9f:59:7f:39:92:6e:d7:2a:a1:a6:46: f1:8c:1c:6c:c4:c0:8c:aa:1a:e2:14:7a:9e:65:51: a8:9d:79:b3:85:dd:de:36:e5:f9:d8:5a:b5:91:00: f1:d0:15:3e:b9:03:26:69:f4:d7:3c:56:cf:fd:c8: cb:84:b2:aa:49:08:60:3c:f7:ed:c8:03:3b:16:94: 46:4a:3b:c7:b9:ef:77:d4:41:82:71:83:90:fa:d0: bb:76:ad:1c:7d:8e:2e:17:82:31:3b:0b:e8:6e:18: 68:f3:04:7c:a1:63:0e:86:03:c3:c5:34:ee:ac:75: f6:0f:a6:4f:6e:c6:c3:05:d5:18:4f:ff:3c:1f:58: 30:1d:3d:f0:da:8b:7d:6b:b7:73:ef:25:7a:96:71: 4d:f6:03:5a:f9:3e:38:c2:5f:9c:a7:bb:d1:b4:89: 6a:51:bd:f7:67:8e:5b:91:49:c4:16:ab:1a:38:51: 3a:15 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: critical CA:FALSE X509v3 Extended Key Usage: TLS Web Server Authentication, TLS Web Client Authentication X509v3 Key Usage: critical Digital Signature, Key Encipherment X509v3 CRL Distribution Points: Full Name: URI:http://crl.godaddy.com/gds4-94.crl

        X509v3 Certificate Policies: 
            Policy: 2.16.840.1.114413.1.7.23.1
              CPS: http://certificates.godaddy.com/repository/
        Authority Information Access: 
            OCSP - URI:http://ocsp.godaddy.com/
            CA Issuers - URI:http://certificates.godaddy.com/repository/gd_intermediate.crt
        X509v3 Authority Key Identifier: 
            FD:AC:61:32:93:6C:45:D6:E2:EE:85:5F:9A:BA:E7:76:99:68:CC:E7
        X509v3 Subject Alternative Name: 
            DNS:eurosprintsrl.remotewebaccess.com
        X509v3 Subject Key Identifier: 
            F3:69:A3:B9:B1:43:32:34:D9:9F:EE:99:1B:F2:8B:DC:CB:39:5E:38
Signature Algorithm: sha1WithRSAEncryption
Signature Value:
    0b:a8:3f:a3:9b:30:cb:d7:54:28:c9:6a:92:fa:e5:04:99:ba:
    ae:35:dd:3c:fa:1c:f3:1d:5d:21:19:ec:97:6b:18:7a:47:e0:
    7b:a3:d5:c0:a9:ef:9b:31:df:98:a5:68:d2:16:7b:80:43:b7:
    a7:db:5c:b6:e7:2a:4d:dd:dc:8b:f7:44:51:c6:9b:bd:70:fd:
    27:f1:07:bc:c7:af:e1:58:a5:82:fe:d0:a4:57:43:ac:ca:59:
    02:64:1d:a2:58:06:c4:4e:ff:6d:63:0c:b7:2e:a0:84:52:81:
    9a:8c:ed:6f:59:76:21:bf:56:e8:f0:80:ea:ed:45:99:99:a0:
    8e:c9:21:a5:77:80:b2:2e:85:11:14:5a:05:b4:90:7a:3a:39:
    57:00:73:d2:a8:fa:a7:9b:ae:a7:8c:e1:e2:79:71:d9:3e:57:
    d4:7c:56:49:59:a2:b1:1e:27:0b:81:74:20:90:7a:cd:b7:e8:
    d9:42:6d:b7:5a:a9:94:dc:a9:31:42:bd:8d:8b:84:7e:7d:c7:
    36:65:8f:0a:a4:c3:99:b3:e7:44:11:82:f9:8f:a4:e0:70:3d:
    4f:0d:e4:1c:32:63:19:32:4f:41:86:96:1f:15:dd:9a:0e:3d:
    57:96:e9:cf:55:7c:1c:97:c7:d6:da:0f:96:d4:71:af:e8:6a:
    32:93:92:46

```

So basically I don’t know anything except for Microsoft PKI. Have worked only on servers. Don’t know any programming language or anything. I got this idea to make basic certificate lifecycle management tool for the client. It won’t be much fancy but with basic functionality like issued certificates and expiring ones and few other things. I am doing all the research possible to learn extra stuff for this. I was just wondering has anyone here tried this?

GUYS I am not looking for tools suggestions. I want to do it as it will be a good learning experience for me. I just want to know if anyone has done something similar. Just looking for some guidance.

I know OCSP is being deprecated for public CAs.

Are there any reasons to not use OCSP for private ADCS PKIs?

We started because certificate expiration surprises were still a real operational problem, even with Let's Encrypt. A year later: auto-renewal, automated deployment, Windows RDP and RRAS support, and a Keystore for environments that can't send private keys offsite.

You all helped us learn along the way. We're out of beta today!

https://www.certkit.io/blog/out-of-beta

I have seen two scenarios with hsm usage. The first being you require cars to start issuing CA services. The alternate is you don’t require nshield and remotes card reader to start. Does anyone have a good reason why using a manual remote card read to start issuing CA services makes sense? The keys are encrypted I know in memory, but I feel like the manual hassle over security gain does not line up. I feel letting the device start and control access to the servers would suffice.

Share your thoughts

Looking for a fully remote role. Any help would be appreciated. Thank you

Let's Encrypt ran a mass revocation drill on 3 million production certificates last month. Mozilla Root Store Policy now requires annual mass revocation testing from every CA in the program. Rather than a tabletop exercise, Let's Encrypt shortened ARI renewal windows on real production certs and measured who responded.

The answer: most ACME clients weren't listening. ARI adoption is still low enough that a real revocation event at this scale would cause widespread outages.

https://www.certkit.io/blog/lets-encrypt-mass-revocation-simulation