This question is about encryption in data communications, defined broadly to include:

  • Line scrambling at layer 1
  • MACsec at layer 2
  • IPsec at layer 3
  • TLS at layer 4
  • etc.

All of these encryption methods require secrets to be installed on the device, such as:

  • Pre-shared secret keys for symmetric encryption
  • Private keys corresponding to the certificate of the device itself.
  • etc.

There may also be some material that must be protected from manipulation but which is not per-se secret, for example the certifates of the trusted root certificate authorities, the certificate of the device itself, etc.

My questions is: what is/are the standard way(s) for installing and managing (e.g. rolling over, revoking, etc.) these secret and sensitve materials on the devices?

An hour or so of Googling seems to indicate that the major network vendors universally seem to use the following approach:

(a) Secret keys are configured using the CLI (or management interface, e.g. NETCONF). They even show up in show config, albeit behind a very thin layer of obfuscation.

(b) Certificates are installed as local files, either copied using SFTP etc. or with a simple CLI front-end.

Is that indeed the state of the art?

Does any network equipment vendor support KMIP / PKCS #11 etc. to interoperate with a key management system (KMS) for key exchange and key management functions?

2 Answers 2


I believe every device which supports a FIPS mode will allow generating encryption keys and certificate signing requests locally (JunOS KB example.) This allows you to avoid extracting crypto material from the device. It shouldn't be possible to be FIPS-compliant without these features.

That doesn't necessarily mean they'll support specific key management technologies.


SCEP (https://en.wikipedia.org/wiki/Simple_Certificate_Enrollment_Protocol) is another protocol to get CSRs from and certificates back to a large number of devices - provided they can generate their own key pairs, pack half of it into a CSR, an submit them using some HTTPish request.

I used to run SCEP on Cisco gear for a few banks' IKEv2 based site to site VPNs. IOS and IOS-XE have a SCEP client built-in, even an SCEP server can be turned on pretty easily.

The only "work" involved on a SCEP client device is:

  • configure the client part (crypto pki trustpoint ...) and define where you want the keys and certificates stored locally.
  • authenticate the CA (i.e: fetch the CA's cert resp. public key) (crypto pki authenticate ...)
  • check the CA cert's fingerprint,
  • enroll the client (Sumit CSR and fetch certificate) (crypto pki enroll ...)

Then there's also client side options/features to auto-renew the enrollment, and CA server side options (if IOS or IOS XE based) to grant requests automatically or manually, export a CRL etc.

It's quite possible that Cisco's SCEP framework (if I may call it so) may not live up to the highest technical standards, for example, there's no OSCP service included, as far as I know, and you'll need to export and host the CRL somewhere outside the CA - but it beats manually handling files and copypasting keys and CSRs by a mile.

Once the cert is on a router, there's a few things one can do with it (provided it's got the right key usage flags) - but since it's routers we're talking about, it will proably mostly be VPN (SSL, IPSec) related things.

  • ... and if one happens to have a competent and willing Windows admin within reach, one can even run IOS/IOS-XE's SCEP client against a Windows based SCEP server (AD integrated or standalone). In that case of course, OSCP/CRL-Hosting might "come with the package", but one needs to be careful if and which revocation information goes into the Cert. After all, another device/instance (the VPN hub router, for example), after finding OCSP info in the cert, might insist to to valiadate that spoke router's cert before allowing it to connect. That OSCP server had better be reachable... Sep 18, 2020 at 16:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.