Feature Request: SCEP Support?

[deknos]

Subject of the issue

Hi, do you plan to support SCEP (https://tools.ietf.org/html/draft-nourse-scep-23) in your Client tool and server? I couldn't find it in your repository. It would be tremendously useful. If you support it in your client, it would help adoption and migration rate, i bet :)

[mmalone]

Do you have a specific use case or tool in mind that you’d like to integrate with? SCEP has some features that seem reasonable and others that I’m less excited to implement. It’d be a lot easier to implement the relevant subset, whatever that is.

[deknos]

Well, for one thing, SCEP is a standardized framework which is easier in an enterprise environment to accept for the auditors. Further on it makes a migration from another CA Certificate software to smallstep easier because you did not have to change the client (initially?) when you migrate from your old version away.

What are the features you do not want to implement? and why? i never encountered problems (besides old/broken implementations) with scep clients. sadly there is currently no enterprise-ready opensource scep server (and opensource enterprise ready scep client, which is multiplattform).

[mmalone]

I'd say the biggest problem here for us is a lack of familiarity with SCEP. If lots of people are using it in the enterprise I'd like to understand the use cases better, but I don't know how to do that.

I've also read a bit of the SCEP spec (er, draft spec) and there are a few optional things and vague bits that I'm not sure how to implement in a vacuum. So I think the easiest thing to do would be to target a few specific pieces of existing software that use SCEP and try to work with them (e.g., take an existing client and try to be a server for it or vice versa). Do you have any suggestions re: common tools that we should look at for this? Does AD or something else really common use SCEP?

[deknos]

Well, we used for a setup OpenXPKI (server https://hub.docker.com/r/dime/openxpki/dockerfile). But it is kinda outdated because they cannot reimplement their engine on a newer version in combination with openssl. tragedy, because their templating system was really good. but that was not our main point why we used it. We used it because of the client (https://github.com/certnanny/sscep), which at that point implemented it very good in comparison to ipsec_scep-client, which... sucked. But ITSecurity and Regulations LOVE SCEP.

Implemented procedure was like that:

We rolled out clients with a initial token with which the client computers could fetch/request from a server with a certain ip in a certain timeframe a certificate for that computer. After that, the token was deleted. With that Certificate another certificate was requested/negotiated.

the first certificate was used to reauthenticate against the PKI Server, the second one was used for 802.1x reasons.. or for system certificates or sth else. We had a daemon which routinely checked if the certificate was half past its lifecycle and tried to update the certificates based on it.

In some instance we could generate the request ourselves, in others we had to take the management-certificate given to us by the server.

Microsoft ActiveDirectory CAN use SCEP, that was the point why we wanted to use it, because in production we couldnt go against openxpki, but against the ActiveDirectory PKI Managementserver which had an SCEP-Interface, so our linux desktop clients could authenticate against that PKI stuff.

And that would be the point, if anyone want to replace their (older) PKI stuff they often implement SCEP internally as transport/negotation protocol :)

Does my rambling make it more clear?

[alkuzad]

@deknos SCEP looks like SOAP compared to REST, abandoned by every dev on the planet and still used in outdated, legacy software :)

[dkmbw]

Well, yeah, but it is an standard used in enterprise environment. and it IS pretty robust.

[anlx-sw]

SCEP is the only way currently (afaik) to automate network device certificate management (or integrate linux servers) with a microsoft windows server certificate authority. It is named NDES there https://social.technet.microsoft.com/wiki/contents/articles/9063.active-directory-certificate-services-ad-cs-network-device-enrollment-service-ndes.aspx .

The implementation and documentation of the microsoft solution is awful in my opinion -but it is used for some use cases frequently: -network device certificates (e.g. for ipsec vpn) e.g. fortinet firewalls have a scep client for installation and management of ca and client certificates https://docs.fortinet.com/document/fortigate/6.2.1/cli-reference/294620/certificate-local To request a certificate on a fortigate firewall with a pki challenge requested from the microsoft ca you can use the following command: exec vpn certificate local generate rsa <certlabel> 2048 <ip fortigate> null null null <companyname> null null null http://<microsoft-ca-server>/certsrv/mscep/mscep.dll <PKI Challenge> <ip fortigate> -mobile device management software often has a scep interface to request certificates on behave of the mobile devices and afterwards pushing the certs to the device

[mmalone]

Thanks for all the links & context folks. This is all super helpful. Please keep it coming!

In particular, please keep posting clients and servers that you're using if you're using SCEP. One of the big problems I have here is that, afaik, SCEP was never officially standardized. There are a bunch of different drafts, and I'm not sure which one to implement against. If there's a "gold standard" SCEP client that everyone uses we'd at least have a de-facto standard to work against, but that doesn't seem to exist either. Failing that, having a list of clients that people use is helpful. Ideally we need stuff that's easy for us to setup and test with, since we don't have our own existing SCEP environment.

It sounds like SCEP is used primarily in two environments:

• By network gear (I've heard Cisco stuff uses it)
• By managed endpoints (sounds like mostly in Microsoft environments)

For the latter scenario, if the endpoint is managed, why not use the step command-line tool instead of an SCEP client? If we had a Windows build of that tool would that solve your problem, or are there other reasons to prefer SCEP (e.g., are the clients more trusted or built-in)?

I'm also curious if the ACME support we just announced would work for some folks? I think informally ACME is IETF's replacement for SCEP, so it feels like the future here. I don't want to be dismissive though -- we need to operate in today's reality too. Just wondering.

[dkmbw]

There's another environment: Linux Appliances/Hosts/Server fetch Certificates via SCEP from Windows Certificate Server/CA/.. (automated), because it is often in a windows based environment the only possibility to get the certificates. and ACME will be not rolled out in enterprise for a long time. And ACME and SCEP serve different purposes from my POV.

Why not use step? because SCEP is a standardized protocol in enterprise environment, and there are ports open for it, and it is supported by monitoring. step communication cannot be monitored in the standard environment and has to be cleared extra by the infosec department. which hinders adoption really much.

[anlx-sw]

concerning implementation:

i worked with a vendor a few years ago to get scep into their appliances and at that time https://tools.ietf.org/html/draft-nourse-scep-23 was used. I think most of the scep implementations are from the time when this draft was current.

I don't know if their are really any differences between the draft there and the current version https://datatracker.ietf.org/doc/draft-gutmann-scep/?include_text=1

Here is the history of the scep draft: https://datatracker.ietf.org/doc/draft-gutmann-scep/history/

Peter Gutmann pgut001 @ cs.auckland.ac.nz is the person which uploads new versions for review.

Concerning adoption: SCEP is one option used I'm aware of to get corporate certificates to ios and android devices: Examples: https://www.manageengine.com/mobile-device-management-msp/help/profile_management/ios/mdm_scep.html https://support.microsoft.com/en-us/help/4457481/troubleshooting-scep-certificate-profile-deployment-in-intune https://docs.sophos.com/central/Mobile/help/en-us/esg/Sophos-Mobile/references/ConfigurationSCEPSophosContainerAndroid.html

The other option is to generate the private Key on the MDM with an "enrollment agent" and push the public and private key to the device.

[dkmbw]

Another thing, regarding implementation: there is a go scep proxy (https://github.com/micromdm/scep) but this is from my POV not enterprise-grade as your product. As client implementation for scep you could test against, there are the scep client from strongswan/openswan on linux, which in my experience is a little bit broken, but there exists also as client https://github.com/certnanny/sscep which is used in at least 2 enterprise environments.

[rmhrisk]

Microsoft's use of SCEP in Intune is proprietary, they have included additional proprietary meta in extensions and taken some narrow interpretations of the SCEP specification that must be teased out in testing.

While the SCEP RFC drafts are useful because of there never been a final RFC not one of those drafts reflect reliably what is needed for interoperability, at least in a broad way.

To support SCEP you will need a list of products you want to interoperate with and build and test with those specifically in mind otherwise you will just have another SCEP implementation full of your own assumptions and not one refective of what is out there.

[dkmbw]

@rmhrisk at least sscep from keynanny/certnanny can handle SCEP-Communication with some Microsofts SCEP implementations. if you wish i can look for the implementation versions of the AD/CA-Service.

And Keynanny/certnanny has an scep server as well, named openxpki. you could observe and learn from their scep implementation as well from the C version of strongswan

[rmhrisk]

I have done many SCEP implementation so I am familiar. My point remains the same if you want to add SCEP you will need to know what implementations you want to interoperate with and not rely on the RFC.

[sdktr]

We’re looking into scepman, /bc scep is supported by Intunes MDM (does windows 10 as well). When there is no other user/device backend then Azure AD it is very powerfull to have any sort of PKI authenticate to this, like your OIDC provisioner does. In this case it’s scep because the intune client on a mobile device supports that. It provides for a great silent deployment option for wireless/vpn authentication on managed devices. https://scepman.com/ To replace this an Intune provisioner and SCEP interface should both be available. This Microsoft doc has a nice overview: https://docs.microsoft.com/en-us/intune/certificate-authority-add-scep-overview

[mmalone]

This is all super useful folks. Thanks so much.

If you're reading this, haven't commented, and this is something you want please leave some indication (e.g., give the issue a 👍) to help with prioritization.

To support SCEP you will need a list of products you want to interoperate with and build and test with those specifically...

This is what I was afraid of.

What I'm gathering is that there are two primary use cases:

• MDM cert enrollment integration for endpoint devices (Windows, macOS, i-devices, and even ChromeOS apparently)
• Enrolling network devices (primarily Cisco?)

Please continue to leave notes on clients and existing SCEP CA implementations that you use or that you know are in use elsewhere.

To move forward with this I think we'll have to do as @rmhrisk suggests, synthesize this feedback, and put together a list of clients that we want to support. The next step will be figuring out how to run them... I have no experience with MDM and we don't currently own a Windows machine or Cisco network gear at smallstep. So we'll have to get that all sorted out!

The reason I'm curious about existing CAs is that might be a shortcut... if all of the existing clients work with Windows Certificate Server, for instance, we could base our implementation off of theirs vs. looking at all the clients.

[anlx-sw]

yes - i think you are onto something - most commercial products will work with Windows Certificate Server NDES because of the installed base in windows ad environments.

Concerning network device enrollment: Modern Firewalls have lots of use cases for certificates. certificate based ipsec vpn is the most prominent.

I know that two of the biggest players in this market support scep: PaloAlto https://docs.paloaltonetworks.com/pan-os/8-0/pan-os-web-interface-help/device/device-certificate-management-scep# Fortinet https://docs.fortinet.com/document/fortigate/6.2.1/cli-reference/294620/certificate-local

[willglynn]

@mmalone Mikrotik RouterOS is a networking Swiss Army chainsaw, and it includes a SCEP client and server. RouterOS does not talk ACME, so SCEP is the best way to automatically obtain certificates on this platform. SCEP server support in step-ca would be useful to me for use with RouterOS clients.

Mikrotik distributes "Cloud Hosted Router" VM images which run on normal x86-64 hosts. There are paid licenses available, but they're not needed here:

The free license level allows CHR to run indefinitely. It is limited to 1Mbps upload per interface. All the rest of the features provided by CHR are available without restrictions. To use this, all you have to do is download disk image file from our download page and create a virtual guest.

RouterOS can be run via qemu inside Docker, which might be a viable path for making a third party SCEP appliance available in development or CI.

[dkmbw]

The CertificateSoftware EJBCA and Dogtag from RedHat also support SCEP by the way (OpenXPKI (server) an Keynanny (SCEP Client) are already mentioned above).

And there is already an prototypical implementation of scep with go: https://github.com/micromdm/scep !

[deknos]

btw, there's a new RFC in town, now. EST. testable via http://testrfc7030.com and it seems to be the successor to SCEP. But i am not aware of any client which is able to use it on linux.

[rmhrisk]

EST support in devices is very limited. It’s better designed than SCEP though.

[datduke-git]

Anyone able to get SCEP to work on iOS via Intune MDM via an apple config profile? I have it working using the GUI profile within Intune/Azure. I am trying to export/compare those values and import to an apple config profile. There is a bug with enforcing wifi via the device/mdm restrictions - the root, scep and wifi profiles do not come down together and brick the device. Trying to pull everything into one apple config profiles with multiple payloads.

[brotherdust]

@mmalone Mikrotik RouterOS is a networking Swiss Army chainsaw, and it includes a SCEP client and server. RouterOS does not talk ACME, so SCEP is the best way to automatically obtain certificates on this platform. SCEP server support in step-ca would be useful to me for use with RouterOS clients.

Mikrotik distributes "Cloud Hosted Router" VM images which run on normal x86-64 hosts. There are paid licenses available, but they're not needed here:

The free license level allows CHR to run indefinitely. It is limited to 1Mbps upload per interface. All the rest of the features provided by CHR are available without restrictions. To use this, all you have to do is download disk image file from our download page and create a virtual guest.

RouterOS can be run via qemu inside Docker, which might be a viable path for making a third party SCEP appliance available in development or CI.

Came here to mention my use-case, but @datduke-git already mentioned it. More specifically, I use it for TLS connectivity to the router's API, but it can be used for other services in RouterOS as well.

[sbingner]

https://github.com/rgorosito/ejbca/blob/master/modules/ejbca-scep-war/src/org/ejbca/ui/web/protocol/ScepServlet.java might be useful as a reference for adding this support as well.

[trs80]

I'm also interested in SCEP from the MDM (Jamf/Intune) point of view, specifically to distribute certificates for use in VPN and wireless (802.1x).

[tarelda]

@mmalone, I came across step looking for CA solution for my internal VPN needs. AFAIK, all the modern firewalls support SCEP based enrollment. While manually distributing initial certs is something I can deal with, automatic renewal is cumbersome, especially that I want to use short lived certificates.

Also I found these Cisco documents regarding SCEP:

• https://www.cisco.com/c/en/us/support/docs/security-vpn/public-key-infrastructure-pki/116167-technote-scep-00.html - brief protocol description
• https://www.cisco.com/c/en/us/support/docs/security-vpn/public-key-infrastructure-pki/211322-IOS-PKI-Deployment-Guide-Certificate-Ro.html - detailed description how SCEP is used in PKI deployment in Cisco IOS

Also basing on @sbingner 's find and my findings above we only have to implement three methods:

• PKIOperation - CSR handling
• GetCACert - CA root cert retrieval
• GetCANextCert - CA rollover cert retrieval

IMO, seems reasonably easy to do. I wish I was go programmer so I could write some kind of POC.

[brotherdust]

Small step is useless to me until it has SCEP or there's a valid workaround. I'd love to use, even pay money for it!

[hslatman]

Recently I learned a bit about SCEP (and EST) and started to implement small POCs to better understand them. I've created two Caddy modules for this: caddy-scep and caddy-est. Both modules are essentially wrappers for other Go modules providing the actual SCEP and EST functionality on top of Caddy. Caddy uses Smallstep libraries under the hood to provide ACME support and I built the modules to make use of that integration.

Currently the modules should be considered a prototype implementation. I highly doubt they are ready for production usage as is. The interfaces provided by the underlying modules micromdm/scep and globalsign/est seem to work OK, but I'm also contemplating refactoring a bit to not rely on them. They may be of use to this project too.

[TheSecMaven]

SCEP would be a huge add, and super helpful in major enterprise use cases. @hslatman, are you working on this? need help getting it started, I have hours on the weekends haha, this would be a super helpful addition.

[hslatman]

@mkkeffeler Since my previous message I have forked this repo and started working on a bit of SCEP support. It's currently really basic because I need to learn a bit more about the code base to fit SCEP in nicely, so that's why I haven't pushed something to my fork yet. I'll probably work on it again this Friday.

My plan is to integrate parts of the POC Caddy module in a cleaner way in the Smallstep server, similar to how the ACME provisioner is implemented, and doing tests with basic CLI tools. It'll probably require a bit more time to make it work with other technologies mentioned in this issue before.

[TheSecMaven]

@hslatman good to hear, welcome to shoot me a message on the smallstep gitter or elsewhere, i have saturdays with your name on it!

[hslatman]

@mkkeffeler I've pushed some updates to my fork: https://github.com/hslatman/certificates/pull/1. It's quite rough, mostly because I'm not entirely sure how I should provide some fundamental deps to my authority and/or provisioner. A certificate can be claimed successfully with the micromdm/scep client already.

[maraino]

@hslatman Let us know if you have any question, we can also schedule a video conference with the team.

[brotherdust]

Has anyone been successful with this yet? I’ve got a smallstep CA in my home network that I’d really like to use to deploy certificates to all my IoT devices via SCEP. Having SCEP support is the last obstacle to that goal.

[hslatman]

@brotherdust: still working on it. Progress is here: https://github.com/smallstep/certificates/pull/506. You could give it a try for testing purposes :)

[brotherdust]

@brotherdust: still working on it. Progress is here: https://github.com/smallstep/certificates/pull/506. You could give it a try for testing purposes :)

Oh hell yes! I'll try it today.

[maraino]

@brotherdust It will be great if you can try it before merging it. I still have to do a last look, I've been quite busy lately, but we should merge soon.

[brotherdust]

Ok so maybe not today. Too much work. Tomorrow for funnies.

[brotherdust]

@maraino , sorry, got distracted. Trying it now... and it had to be the moment that smallstep's servers died so I can't read the docs. lol

[dopey]

Hey @brotherdust which docs are down for you?

[brotherdust]

Hey @brotherdust which docs are down for you?

The smallstep docs. It might be me. I'll check again soon

[brotherdust]

@brotherdust: still working on it. Progress is here: https://github.com/smallstep/certificates/pull/506. You could give it a try for testing purposes :)

Ok. So I got the referenced pull request compiled. It's not all that clear to me how to enable SCEP. The pull request says it works with micromdm, so I assume there must be some kind of integration happening here? Sorry, I'm used to how SCEP and NDES works with Windows CA.

Update: nevermind, I found some instructions in the pull request. I'll follow those.

[brotherdust]

@dopey , just so you know, it looks like the docs are unavailable via IPv6. I turned off IPv6 and I can access them now. smallstep.com resolves to 2604:a880:400:d0::1741:7001 and 2600:1f18:2489:8201:aeea:87a5:6524:10fd, both of which are pingable but don't seem to want to respond to my request.

[maraino]

@brotherdust @dopey I've just disabled IPv4 and it's working fine for me on IPv6. And without messing up with your network you can also test it with:

curl -k -H 'Host: smallstep.com' https://\[2604:a880:2:d0::2103:a001\]

[maraino]

@brotherdust It resolves for me to different IPs for me:

$ dig AAAA smallstep.com
...
smallstep.com.      1   IN  AAAA    2600:1f1c:471:9d00:64a9:5908:2245:64e0
smallstep.com.      1   IN  AAAA    2604:a880:2:d0::2082:a001

[brotherdust]

@maraino , don't sweat it. I can access it via IPv4 so I'm good. It's probably me. I have lots of weird network settings due to all the labs I run.

[hslatman]

@brotherdust: regarding micromdm; that's one of the SCEP client implementations that I used to test. There's no hard requirement to use it for your tests.

Some instructions for getting step to serve SCEP are in the PR, but they may have been hidden for you: https://github.com/smallstep/certificates/pull/506#issuecomment-798987601. You'll need to ensure to run step with RSA keys, because that's what's currently supported and in the SCEP RFC. You'll have to adapt your client to make use of the SCEP provisioner that you configure.

Let me know if you hit a blocker.

[hslatman]

And then I saw your edit 😅

[maraino]

@brotherdust FYI: The PR is approved, but I want to go through the implementation to add the errors in the logs because right now it's quite hard to know what is going on, as some of the errors are only surfaced encoded in the pkiStatus.

For example, you might find an error trying to sign a too small key (RSA 1024) while step-ca internally has a requirement of 2048 bits. You will have to actually do some debugging to figure out what the error was. I want to show this error to the step-ca logs.

We might consider at some point reducing this for SCEP if this is a problem for real use cases, but at the moment this is a requirement.

[hslatman]

@maraino: note that I have (at least partially) addressed those issues in my most recent commits.

I'm working on more tests, incl. full CA config with SCEP enabled.