VPN certificate inventory: what the CA ledger can prove
A server folder, a CA ledger, a revocation list and a session table answer different questions. Keep them apart when you inventory VPN identities.
Your gateway accepts a client certificate it has never seen, because what it was configured with is a trusted issuer and the certificate arrives during the handshake. That is how the protocol is meant to work, and it is also why a directory listing on the server makes a poor inventory. The issuer knows what it created, the server knows what connected, and the revocation state knows what was withdrawn. An inventory that blends those three records ends up asserting something none of them said.
The gateway trusts an issuer, not a file listing
Validation compares a presented certificate against a trust anchor, so an identity created yesterday by the same issuer connects without ever having existed on the server's disk. Nothing needs to be copied for that to happen, and nobody has to approve it by hand. The server's own records therefore describe arrivals, not the population of identities that could arrive.
The reverse gap is just as awkward. A directory can hold expired certificates, revoked ones, and identities issued for devices that were never deployed. Counting files answers how many files are present, which is a question nobody asked. Start from the records that carry meaning instead.
Four questions, four different records
Each record type answers one question well and the others badly, which is why a report that merges them looks complete while being wrong in a specific way. The table below sorts them by the question they settle rather than by the system that produces them.
| Question you are answering | Where the answer lives | How quickly it changes | What it will never show |
|---|---|---|---|
| Was this identity ever created? | The issuer's issuance database | Only when something is issued | Whether the device still exists |
| Is a copy sitting on this host? | The paths you actually inspected | Whenever anyone copies files | Certificates that were never copied here |
| Has the issuer withdrawn it? | Published revocation state | When the issuer next publishes | Withdrawals that are not published yet |
| Is it connected right now? | The live session table | Continuously | Anything about past or future sessions |
An archive of public certificates is not a secret, since it holds no private keys, but it is not shareable either. Subjects and device names reveal operational detail, and the report should stay with the audience that needs it. Private keys stay out of the inventory entirely, because the inventory needs metadata rather than credentials.
Issuer plus serial is the only stable key
Subjects get recycled and filenames get reused, so a name that identified one device last year may identify a different one now. Neither is a key, and a report built on either will eventually merge two identities into one line.
The pair of issuer and serial identifies a certificate uniquely, and both fields come out of the certificate itself. Record them with the subject, the validity dates, the source the copy came from, and the person or device responsible. Add revocation and deployment status as separate fields with their own observation times, because a certificate inside its validity window is not automatically authorized. Those two facts live in different systems, and collapsing them conceals the case where an identity was withdrawn while its file still looks current.
Read one certificate at a time
A wildcard that expands across a directory is not a batch interface, and it hides which file produced which output. Read the metadata per certificate, and read the revocation side from its own artefact. The OpenSSL x509 reference lists the fields those options print.
openssl x509 -in <cert>.pem -noout -issuer -serial -subject -dates -fingerprint -sha256
openssl crl -in <issuer>.crl -noout -text | head -n 40For a managed Easy-RSA PKI, query the issuance database through the workflow the tool supports rather than assuming a directory layout, and keep the originals read-only while the inventory is assembled. The ledger format is regular enough to count valid entries and list the withdrawn ones without opening the database by hand.
grep -c '^V' pki/index.txt
grep '^R' pki/index.txt | cut -f4,5An inventory that survives the next issuance
A one-time dump of a directory is stale the moment the next certificate is issued, so build the report from the issuance workflow and let it update as part of normal operation. That also makes the report reproducible, which matters when two people disagree about what was issued.
Use the result for renewal and retirement decisions rather than as a spreadsheet exercise. Deleting a local copy does not invalidate the remote copies that already exist. Withdraw the identity through the configured revocation and authorization workflow, then record the withdrawal with its date. An identity that has vanished from the server but is still trusted by the issuer has not been retired, and that difference separates an inventory that is accurate from one that is merely reassuring.