Repository navigation
feat(scep): serve SCEP so network devices can enrol a trustpoint #185
Description
Network equipment cannot use ACME. Cisco IOS/IOS-XE, and most switch, router, firewall and VPN platforms, enrol a trustpoint over SCEP. Without it every network device certificate is a manual CSR ferry, and there is no renewal path.
Concrete driver
One estate has a Cisco C9300X stack and Dell OS10 leaves that will eventually need identity certificates for 802.1X, RADIUS/EAP and management TLS. On IOS-XE that is:
crypto pki trustpoint EXAMPLE_CA
enrollment url http://<ca>/cgi-bin/pkiclient.exe
subject-name CN=switch01.example.com
crypto pki authenticate EXAMPLE_CA
crypto pki enroll EXAMPLE_CA
There is no ACME client on that platform, so SCEP is the only automated option short of hand-carrying certificates.
Scope
Implement the SCEP server operations (RFC 8894):
GetCACaps,GetCACert,PKIOperation(PKCSReq, GetCertInitial, GetCRL)- CMS/PKCS#7 request and response handling
- issue through the existing profile machinery so
ca.Profilestays the single place extensions are decided - record issued certificates in the revocation set so SCEP-issued certs are revocable and appear on the CRL
Notes
- SCEP is RSA-centric: most devices generate RSA keys and many cannot do EC at all. Depends on RSA subject-key support (feat(node): accept RSA subject keys in signed CSRs #182).
- Enrolment authorisation needs deciding. SCEP traditionally uses a challenge password, which is a shared secret; that is weak but is what the devices support. Worth designing deliberately rather than defaulting to it.
internal/ca/doc.goalready lists SCEP as anticipated adapter work, wire-format only with issuance staying in our own CA path. This issue follows that.
Out of scope
ACME (#184) and EST, tracked separately.
Activity
Bugs5382 commentedon Sep 30, 2026
Design decisions (owner, 2026-09-30):
Bugs5382 commentedon Sep 30, 2026
Clarification on D7 (owner, 2026-09-30): the key size is a minimum per profile, not a fixed size. Cisco IOS and IOS-XE SCEP trustpoints are limited to RSA 2048, so the Cisco device profile uses the 2048 floor, and live validation on the IOS-XE trustpoint (C9300X) runs with RSA 2048. 2048 is the lowest any profile may allow. Devices that can do more (for example some MDM clients) get a profile that requires RSA 3072+ or ECDSA P-384, and stronger keys are always accepted on a lower-floor profile. CA, RA and server keys stay RSA 3072+ or P-384.
feat(ca): allow a per-profile RSA subject-key floor down to 2048
feat(scep): serve SCEP (RFC 8894) so network devices can enrol
Bugs5382 commentedon Sep 30, 2026
Slices 3 and 4 are up as #288 (stacked on #285), with the docs page in CryptOS-PKI/docs#40. Small things found and handled there:
-c, so in RA mode that is the RA, and it then names the RA as the issuer in GetCert and GetCRL. The server accepts the RA's name there as well as the CA's.docs/est.mdstill described SCEP as a shared secret on every device; one sentence is corrected in feat(scep): serve SCEP so network devices can enrol a trustpoint #288.Still owed before this issue closes: live validation on the C9300X (IOS-XE trustpoint with RSA 2048, enrol, rollover renewal, a PENDING profile, a revoked-device refusal).
docs(using): add the page for enrolling devices with SCEP
feat(ca): allow a per-profile RSA subject-key floor down to 2048
feat(scep): serve SCEP (RFC 8894) so network devices can enrol
Bugs5382 commentedon Sep 30, 2026
Reopened until #288 (the SCEP server) merges; that PR closes it.
feat(ca): allow a per-profile RSA subject-key floor down to 2048
feat(scep): serve SCEP (RFC 8894) so network devices can enrol
feat(ca): allow a per-profile RSA subject-key floor down to 2048
feat(scep): serve SCEP (RFC 8894) so network devices can enrol
feat(scep): serve SCEP so network devices can enrol a trustpoint (#288)