Device Certificates and CSRs — What They Are and How to Generate One

A device certificate binds a device’s identity to a public key, signed by a certificate authority that both sides trust. It is what lets a device prove it is what it claims to be, rather than relying on a shared password that anyone who has it can use.

A CSR (Certificate Signing Request) is the application. The device generates a key pair, keeps the private key, and sends the public key plus its identity details to the CA. The CA verifies the request and returns a signed certificate.

The critical property: the private key never leaves the device. That is the whole security model. If a private key is emailed around or copied between servers, the certificate no longer proves anything about which device is presenting it.

Table of Contents

Certificate vs CSR vs Key

	Contains	Shared?	File extension
Private key	The secret half of the key pair	Never	.key, .pem
CSR	Public key + identity details, self-signed	Sent to the CA	.csr, .req
Certificate	Public key + identity + CA signature	Presented publicly	.crt, .cer, .pem

What Goes in a CSR

Field	Meaning	Example
CN (Common Name)	The primary identity — hostname or FQDN	router01.example.com
O (Organization)	Legal organisation name	Example Ltd
OU (Organizational Unit)	Department	Network Operations
L / ST / C	Locality, state, two-letter country code	London / England / GB
SAN (Subject Alternative Name)	All names and IPs the certificate covers	DNS:router01.example.com, IP:10.0.0.1
Key type and size	RSA 2048+ or ECDSA P-256	RSA 2048

The SAN field is the one that matters

Modern browsers and TLS libraries ignore CN entirely and validate against Subject Alternative Name. A certificate with the right CN and no SAN will be rejected outright — this has been the case since Chrome 58 in 2017, and it is the single most common cause of a newly issued certificate failing to work.

Every name and IP address the device will be reached by must appear in SAN. If people connect by both router01 and router01.example.com, both belong there.

Generating a CSR with OpenSSL

# One command: generate a 2048-bit key and a CSR
openssl req -new -newkey rsa:2048 -nodes \
  -keyout router01.key \
  -out router01.csr \
  -subj "/C=GB/ST=England/L=London/O=Example Ltd/CN=router01.example.com"

To include SAN entries, use a config file — the command line alone will not carry them through reliably:

cat > csr.conf <<'EOF'
[req]
distinguished_name = dn
req_extensions     = ext
prompt             = no

[dn]
C  = GB
ST = England
L  = London
O  = Example Ltd
CN = router01.example.com

[ext]
subjectAltName = @alt

[alt]
DNS.1 = router01.example.com
DNS.2 = router01
IP.1  = 10.0.0.1
EOF

openssl req -new -newkey rsa:2048 -nodes \
  -keyout router01.key -out router01.csr -config csr.conf

Always verify before sending it to the CA — a CSR with a missing SAN wastes an issuance cycle:

openssl req -in router01.csr -noout -text

Generating a CSR on Cisco IOS

! 1. Key pair — exportable only if you genuinely need a backup
Router(config)# crypto key generate rsa label ROUTER-KEY modulus 2048

! 2. Trustpoint
Router(config)# crypto pki trustpoint CORP-CA
Router(ca-trustpoint)# enrollment terminal
Router(ca-trustpoint)# subject-name CN=router01.example.com,O=Example Ltd,C=GB
Router(ca-trustpoint)# subject-alt-name router01.example.com
Router(ca-trustpoint)# rsakeypair ROUTER-KEY
Router(ca-trustpoint)# fqdn router01.example.com
Router(ca-trustpoint)# revocation-check none
Router(ca-trustpoint)# exit

! 3. Generate the CSR — it prints to the terminal
Router(config)# crypto pki enroll CORP-CA

! 4. Import the CA certificate first, then the signed device certificate
Router(config)# crypto pki authenticate CORP-CA
Router(config)# crypto pki import CORP-CA certificate

Two things to get right here. crypto pki authenticate must come before import — the device needs the CA’s own certificate to validate the one it is being given. And the device’s clock must be correct: certificate validation is time-based, and a router with the wrong date will reject a perfectly valid certificate. Configure NTP before enrolling.

Router# show crypto pki certificates
Router# show crypto key mypubkey rsa
Router# show clock

Where Device Certificates Are Used

802.1X — EAP-TLS authenticates devices to the network by certificate rather than password. This is the strongest form of network access control.
HTTPS on management interfaces — so administrators are not clicking through a warning every time, which trains people to ignore genuine warnings.
SSH host keys — proving the device is the one you connected to last time.
IPsec VPN — certificate authentication instead of a pre-shared key, which scales and can be revoked individually.
MDM enrolment — identifying managed devices.
Mutual TLS between services, where both ends authenticate.

Internal CA vs Public CA

	Internal CA	Public CA
Trusted by	Only devices with your root installed	Everything, out of the box
Cost	Infrastructure and operational effort	Free (Let’s Encrypt) to substantial
Suitable for	Internal devices, 802.1X, internal services	Anything a third party connects to
Validity period	Your choice	Capped — 398 days, dropping further
Internal-only hostnames	Yes	No — public CAs cannot issue for private names

For internal network equipment, an internal CA — Microsoft AD Certificate Services, or a small OpenSSL or step-ca setup — is normally the right choice. Public CAs cannot issue certificates for .local or private IP addresses, and paying for hundreds of device certificates makes no sense when nothing outside your network validates them.

Where This Goes Wrong

Missing SAN. The most common failure. CN alone is not validated by anything modern.
Expiry. Certificates expire silently until the day they take a service down. Track expiry dates and alert well in advance — 30 days is not enough for a change process.
Wrong device clock. A certificate valid from tomorrow, on a device that thinks it is yesterday, fails validation with a confusing error.
Private key exposure. Copying keys between devices destroys the identity guarantee entirely.
Incomplete chain. Serving only the leaf certificate without the intermediate works in browsers that cache the intermediate and fails everywhere else — an inconsistency that makes it hard to diagnose.
Weak keys. RSA below 2048 bits, or SHA-1 signatures, are rejected by current software.
No revocation plan. A compromised device certificate needs to be revocable, which means CRL or OCSP has to actually work.

Frequently Asked Questions

What is the difference between a CSR and a certificate?

A CSR is the request — public key plus identity details, self-signed to prove possession of the private key. The certificate is what the CA returns after signing it.

Can I reuse a CSR?

Yes, for renewal, provided the details have not changed and the private key is still secure. Generating a fresh key pair at renewal is better practice.

Why is my certificate rejected despite the right Common Name?

Because CN is no longer checked. Modern clients validate the Subject Alternative Name field, and a certificate without a matching SAN entry is rejected regardless of CN.

What key size should I use?

RSA 2048 as a minimum, RSA 4096 or ECDSA P-256 for longer-lived certificates. ECDSA gives equivalent security with smaller keys and faster operations, but check your devices support it.

Do I need a public CA for internal devices?

No, and usually you cannot use one — public CAs will not issue certificates for internal hostnames or private IP addresses. Run an internal CA and distribute its root to your devices.

What happens when a device certificate expires?

Whatever depends on it stops working — 802.1X authentication fails, TLS connections are refused, VPN tunnels drop. There is no grace period. Monitor expiry dates and renew ahead of time.

Written by

Gurpreet Singh

Hey! I"m Gurpreet Singh and I Have 7+ Years of experience in the Network & Security Domain as well as the Cloud Infra Domain. I am Certified with Cisco ( CCNA ), CheckPoint ( CCSA ), 1xAWS, 3xAZURE, and 3xNSE. So I love to share my tech knowledge with you.