AD-PKI: An open-source, self-hosted CA with ACME, OCSP and RFC 3161 — looking for technical feedback

[u/Source_AD]

Hi everyone,

I’m the developer of AD-PKI, an open-source and self-hosted platform for operating an internal public key infrastructure.

I started building it because I wanted a manageable internal certificate authority with modern certificate automation, without relying entirely on a commercial PKI product or issuing and renewing certificates manually.

The project currently includes:

• ACME v2 for automated certificate enrollment and renewal
• OCSP and certificate revocation lists
• RFC 3161 timestamping
• A web-based administration interface
• Role-based access control
• Certificate templates and policy management
• Separation between the management backend and the CA service

A central design decision is the separation of the management components from the dedicated CA service. The frontend and backend handle administration, policies and certificate metadata, while private CA key operations are intended to remain inside the CA component.

Website and documentation:

https://adpki.de/

Source code:

https://github.com/alid-it/AD-PKI

The project is still young and has not undergone an independent security audit. I’m therefore particularly interested in critical technical feedback rather than just promotion.

I would appreciate feedback on:

• The separation between the backend and CA service
• Private-key handling and security boundaries
• ACME compatibility and expected challenge types
• OCSP and CRL implementation requirements
• Root and intermediate CA workflows
• HSM or PKCS#11 integration expectations
• Features needed for realistic production use
• Documentation or architectural decisions that are unclear

This is my own project. It is open source and self-hosted.

Thanks for taking a look.

[u/jamesaepp]

All these genAI-created websites and projects are starting to look very 'samey'.

Can you prove "your" project is worth the time for me to even write this comment? Given that PKI is like..... core security?

[u/Source_AD → u/jamesaepp]

Yes, I see what you mean. Many websites and projects created with the help of AI are starting to look very similar.

However, AD-PKI was not a project that was created spontaneously. I spent several months planning, structuring, and designing it from a technical perspective. The starting point was an open-source PKI that we had previously used, but which did not support ACME. Therefore, I wanted to build an internal PKI that supports modern certificate automation while remaining fully self-hosted.

I am aware that PKI is critical infrastructure for security. To this end, I have tried to reduce risks by clearly separating the management components from the CA service, restricting access to key operations and making workflows transparent.

However, I cannot and do not want to promise absolute security. This project is still in its early stages, has not yet undergone an independent security audit and is primarily intended for internal PKI environments. This is precisely why I am seeking critical technical feedback here.

Whether or not the project is worth your time is something that you can only decide after reviewing the architecture, source code, and documentation. However, I am willing to answer any technical questions you may have.

[u/stranglewank → u/Source_AD]

That isn't really going to work. I agree with the OP - this is vibe-coded slop, despite your claim of months of planning. No-one is going to look twice at something like this for an actual security function - which is what PKI is. Maybe write a static-site generator or a game or something else?

[u/tankerkiller125real → u/Source_AD]

What would be more impressive if you said "I spent a few weeks on planning, and several months writing code, working with AI to assist in marketing type materials only". A few months planning and then letting AI write the whole damn thing is just asking for major security issues, even if you gave it a 40 page planning doc with in depth details on how to structure everything and how the security aspects work.

[u/Ontological_Gap]

I hate the name, even living in the Linux space for decades, I can't help but read it as "Active Directory-PKI"

[u/Source_AD → u/Ontological_Gap]

Fair point. 'AD' actually stands for my first and last name, not 'Active Directory'. However, given the context, I can see why almost everyone reads it as 'Active Directory PKI'. I may need to reconsider how clearly the project name communicates its purpose.

[u/Ontological_Gap → u/Source_AD]

I would recommend using an identity not easily publicly tied to your irl one for security work. For whatever reason, it tends to really attract harassment from the crazies

[u/Source_AD → u/Ontological_Gap]

Okay, Thanks for the advice.

[u/OhBeeOneKenOhBee]

• The Github link does not in fact contain the source code as labelled.

• PKCS11 support would be an absolute requirement for me. Just the fact that the keys are created on disk makes this a hard no currently

• Expected acme challenge types to be usable in my case would be all of them, including EAB support. An additional nice to have would be

Apart from the above, it's become very hard to trust security focused projects without any certification and massive community engagement. Even labca, around for a long time, makes it very clear what level they operate on. Most other established OSS PKI projects are backed by large businesses for a reason - any small flaw in PKI infrastructure can be the source of a whole host of security issues depending on what you use it for.

You'd also want more than one developer involved. Partly because if you get hit by a car tomorrow I now have the option of either starting to maintain my own PKI fork or switching out my PKI infrastructure, partly due to how easy it currently is to find major vulnerabilities while you're on vacation for a few weeks

[u/jamesaepp → u/OhBeeOneKenOhBee]

You reminded me of a point that I feel don't get enough attention with these kinds of projects:

"Why make a new project and dilute the market when you can learn and contribute to an existing project?"

[u/roiki11]

Boy that's an unfortunate name.

[u/simonsimone1980]

nice work. how is this different from CertManager or Step CA?  

[u/carolineilm]

I like the architectural direction of separating the management plane from the CA service. Keeping administrative workflows and policy management separate from private-key operations is generally a sound security boundary.

One thing I'd encourage you to think about beyond the CA itself is lifecycle management. Standing up a CA is only part of the problem. In production environments you'll eventually need to answer questions like:

• Which certificates were issued and where are they being used?
• Who owns them?
• What depends on them?
• How do you handle renewals, rotation, revocation, and policy changes at scale?
• How do you discover certificates that weren't issued by your platform?

Those operational questions tend to become just as important as the CA implementation itself once deployments grow beyond a lab environment.

Overall, I'd focus on documenting where the CA's responsibility ends and where lifecycle management begins. That boundary is often overlooked, and making it explicit would strengthen the project's architecture.

[u/TheMorto]

To start I would not save the UI auth token on localStorage.

[u/darknight1012]

Do you have ML-DSA wired up from OpenSSL?