Solving EKU issues with SCEPman

Nethmina Gamage

SCEPman is a cloud-native certificate management solution designed specifically for the Microsoft ecosystem.

It provides a fully managed SCEP (Simple Certificate Enrolment Protocol) service running in Microsoft Azure that eliminates the need for traditional on-premises Public Key Infrastructure (PKI) by offering a lightweight, cloud-based alternative.

The problem

We recently implemented SCEPman with a customer who had SCEPman as their rootCA, and onPrem as SubCA (cloud-first strategy).

When uploading the CSR to SCEPman to receive the certificate, SCEPman was continually adding Server Authentication EKU (Server Authentication (1.3.6.1.5.5.7.3.1) – regardless of everything I tried. This resulted in the SubCA capabilities being locked.

SCEPman support mentioned that this EKU is added by default (controlled via AppConfig:DirectCSRValidation:DefaultEkus) in the Azure SCEPman app (not the certificate master) and can be added if it’s not defined.

How did I solve it?

I opted for the route below, as it avoided the need to make changes in Azure, which can be tricky in a production environment.

The configuration that finally worked required me to create the following in a text file and save it with a .req extension.

Note: Remember to change the Subject name to match your organisation & set Exportable = FALSE if you are running this on the same SubCA for improved security, as the private key will be stored on that server.

[Version]
Signature="$Windows NT$"

[NewRequest]
Subject = "CN=endpointfocus,DC=com"
KeyLength = 4096
Exportable = TRUE
MachineKeySet = TRUE
RequestType = PKCS10
HashAlgorithm = SHA256

Enterprise browsers like Island can play a crucial role in managing Shadow AI behaviour. For example, if your organisation blocks certain public AI models, such as DeepSeek, and an employee attempts to access that URL, Island Enterprise Browser will automatically notify them and redirect them to a company-supported product instead. This proactive approach ensures users stay within your defined security perimeter without disrupting their workflow.

[Extensions]
; Basic Constraints (CA)
2.5.29.19 = "{text}ca=1&pathlength=0"
Critical = 2.5.29.19
; Enhanced Key Usage - Enterprise Server/Machine CA
2.5.29.37 = "{text}2.5.29.37.0"

To create a certificate request, I ran the certreq command on the Windows Certificate server.

certreq -new C:\Temp\subca-inf.inf C:\Temp\subca-req.req

This output can then be provided to SCEPman under the “Generic CSR” tab to obtain a certificate for (All Purpose)

While this has not been tested, adding the below should restrict the SubCA from All Purpose to the following:

  • Server Authentication
  • Client Authentication
  • Encrypting File System
  • IPsec / IKE
  • Smartcard Logon
[Version]
Signature="$Windows NT$"

[NewRequest]
Subject = "CN=endpointfocus,DC=com"
KeyLength = 4096
Exportable = TRUE
MachineKeySet = TRUE
RequestType = PKCS10
HashAlgorithm = SHA256

[Extensions]
; Basic Constraints (CA)
2.5.29.19 = "{text}ca=1&pathlength=0"
Critical = 2.5.29.19

; Enhanced Key Usage - Enterprise Server/Machine CA
2.5.29.37 = "{text}1.3.6.1.5.5.7.3.1,1.3.6.1.5.5.7.3.2,1.3.6.1.4.1.311.10.3.4,1.3.6.1.5.5.8.2.2,1.3.6.1.4.1.311.20.2.2

Are we there yet?

Yes! You can now import this certificate into your SubCA computer store and use it in the certificate wizard to obtain the private key.

There are plenty of guides out there for this, so I won’t go into detail. However, feel free to drop a comment if you need more information.