Why Two OpenVPN Certificates Can Share One CCD Policy

A CA can sign two certificates that pick up the same OpenVPN client-specific configuration, and nothing in either certificate warns anyone. Serial numbers differ, keys differ, and the full subjects differ too once an organizational unit changes. The server resolves per-client policy through one name, and that name is the only thing that has to be unique.

The Server Resolves a Name, Not a Serial

With plain certificate lookup, the server takes the common name from the presented certificate and looks for a client-config-dir entry of that name. The serial number never enters the lookup. Two certificates that differ in every field except the common name land on the same file, so the second connection inherits the first device's fixed address and pushed routes.

That is how a CA-side uniqueness check passes while the VPN still collides. The two checks answer different questions.

Decide what the effective name should be before signing anything, and record it beside the device or account it belongs to. A registry of name, owner, purpose and certificate fingerprint covers most deployments. Without one, the certificate archive is the only record of which name belongs to which device, and that archive cannot distinguish an authorized replacement from a second device claiming an existing name. Reserve the name at enrollment, under a lock if two operators can issue at the same time.

Which Name the Mapping Actually Uses

Plain certificate lookup uses the common name. A server set up to map an authenticated username uses that value instead, which makes the certificate common name irrelevant to policy selection. Read the running configuration to see which mapping is in force.

Both mappings can be present at once, and then the result depends on the order in which the server resolves them. A username map that falls back to the common name will quietly accept a certificate the registry never approved. Write the effective name next to the command that produced it so the next operator does not have to rediscover the order. Testing one connection per mapping is cheap and settles the question.

Whatever the mapping produces is the value to reserve. Reserving common names in the CA while the server keys on usernames reserves the wrong thing.

Two CAs Can Approve the Same Name

A VPN service can trust more than one issuing authority, and each authority keeps its own idea of which names are taken. Two independent CAs can both approve the same common name for different devices, and the server accepts both certificates without complaint. Inventory every authority in the trust bundle, not only the one you normally issue from. The failure appears the first time a certificate from the second authority is used.

The same reasoning applies to a CA that enforces full-subject uniqueness rather than common-name uniqueness.

Two certificates sharing a common name but differing in organizational unit have different subjects, so the CA reports no conflict while the server sees one name. Check the setting your issuing tool actually uses instead of assuming a default. The unique_subject handling in the openssl ca documentation is the relevant knob there, and wrappers around that tool commonly expose it rather than replace it.

Renewal Is a Reserved Reuse, Not a Collision

A renewal that keeps the name is a deliberate reuse, and the registry should say so in plain words. Record the old fingerprint and the new one under a single name so a reviewer can tell a replacement from a takeover. The server's duplicate-cn option is unrelated: it governs concurrent sessions, not enrollment or name reservations. Decide how long both credentials may exist and when the old one stops being accepted.

Before handing over the replacement, read back what the certificate actually contains. The subject line is the field the server will map, whatever the file name suggests.

openssl x509 -in device42.crt -noout -subject -serial -issuer

Revocation normally identifies a certificate under its issuer, so retiring one serial does not affect a correctly issued replacement from the same authority. That behaviour is exactly what a clean renewal needs, and it is also why revocation cannot clean up a name shared by two devices. Validate the effective policy name and the assigned address on a test connection before the user sees the device. Then retire the old credential on purpose and record that you did.