Where RSA's n, e, d, p and q Live in a VPN Key File

The letters in an RSA explanation name fields inside one object, not files that a PKI tool hands out. A private-key file holds a structure whose opening fields are public and whose later fields must never leave the machine that terminates the tunnel. Between those two facts sit most of the practical questions about which file answers which question. This runbook reads the structure first, then the commands that inspect it without spilling it.

Confirm the key is RSA before hunting for primes

A certificate proves that some key exists and was signed; it does not prove the key is RSA. Systems can be built on elliptic curves or Ed25519, and the same directory layout serves all of them. Check the algorithm before you start looking for prime factors that were never there.

These three read-only commands answer the question and record the tool version.

openssl version
openssl x509 -in vpn-client.crt -noout -text
openssl pkey -in vpn-client.key -noout -text

The version matters because option names have moved between major releases. In the certificate output, find the public key algorithm line and the key size; in the key output, an RSA key prints a modulus and a public exponent. An elliptic-curve key prints a named curve instead, and no amount of searching will produce n or q from it.

Read the structure instead of the base64

PEM is base64 wrapped in header lines, and decoding it yields DER, which is a serialised structure rather than one enormous integer. RSA private keys travel in two common containers, PKCS#1 and PKCS#8, and both resolve to the same set of numbers.

In the two-prime case the private structure carries nine fields: a version, the modulus n, the public exponent e, the private exponent d, the primes p and q, two CRT exponents and a CRT coefficient. RFC 8017 section A.1 defines those components and the ASN.1 layout, and it also allows more than two primes, which is why a general parser can print extra prime entries. Notice the ordering, because it explains a frequent mistake: the public half is stored inside the private file, so the presence of a public field does not make that file safe to share. Everything after it is the material that has to stay on the host.

Encoding adds a layer that is easy to confuse with content. openssl asn1parse draws the structure as a tree so the field order becomes visible, and it neither decrypts anything nor tells you whether the key is usable.

Match a certificate to a key without printing the key

The question that follows is usually whether a certificate and a key belong together. Comparing moduli answers it, and it also copies private-adjacent material into a terminal transcript that may end up in a ticket. Comparing public halves answers the same question with nothing sensitive on screen.

openssl pkey -in vpn-client.key -pubout -out /tmp/key.pub
openssl x509 -in vpn-client.crt -pubkey -noout > /tmp/cert.pub
cmp /tmp/key.pub /tmp/cert.pub && echo MATCH

Identical files mean the certificate carries the public half of that key, and a difference means you are holding the wrong pair. That mismatch is the most common cause of a tunnel that negotiates happily and then refuses authentication. Remove the two temporary files afterwards; they hold nothing secret, but a clean working directory is easier to reason about halfway through an incident.

Know what the neighbouring files are not

A certificate is not an encrypted public key that the peer unlocks with the CA certificate; it is a signed binding between a public key and identity data. The CA's private signing key stays separate from its own certificate and from every client key. A request is not a certificate either: it carries the requested information and the public key with a signature over the request, which makes it enrollment input rather than proof of entitlement.

Two of those entries get confused with RSA parameters often enough to name them twice. A Diffie-Hellman parameter file contains group parameters for key establishment and no RSA primes, even though it also prints as a large prime. A revocation list publishes certificate status and is not a place where a private exponent could hide.

Every inventory line should therefore record four things: object type, owner, purpose and whether private material is included. The last column decides where the file may be copied, and it is the one people skip.

Record the pairing, then verify the handshake

Before changing anything, save the verification output with the date and the OpenSSL version. A later rotation can then be compared with evidence instead of memory.

openssl verify -CAfile ca.crt vpn-client.crt
openssl x509 -in vpn-client.crt -noout -subject -issuer -dates

After the public-key comparison, exercise the path that consumes the pair: bring the tunnel up, confirm the certificate is presented and accepted, and check which identity the gateway recorded. If the key and certificate match and authentication still fails, the fault lives in trust, identity mapping or access policy rather than in the pairing.

For rollback, keep the previous key and certificate in a dated directory and restore both together, never one of the two. A key without its certificate and a certificate without its key fail identically from the outside, which makes half-restored pairs expensive to untangle at two in the morning.