Intermediate CA
Last updated
Was this helpful?
Last updated
Was this helpful?
SCEPman Enterprise Edition only
If you want to use another Root CA as a primary authority, you can create an intermediate CA certificate to operate SCEPman as a Subordinate Certification Authority. You can create the correct certificate direct in Azure Key Vault and download the CSR for signing with your Root CA. The signed request can be uploaded and merged into Azure Key Vault. This article guides you through the necessary steps in detail.
You need to grant access to the Azure Key Vault to your user account to create the CSR and merge the Intermediate CA certificate. The way of assigning the permissions depends on the access configuration of your Key Vault:
Navigate to your Azure Key Vault in the Azure Portal
Click on Access control (IAM) in the left navigation pane.
Click on Role assignments and add a new role assignment
Select the Key Vault Certificate Officer role and click Next
Now search and add your AAD admin account in the Members section and continue to assign the role
After adding the role assignment, your Azure AD account is permitted to create a CSR and upload the certificate.
Go to Azure Key Vault in the Azure Portal.
Navigate to the Networking blade under Settings.
Switch to "Allow public access from specific virtual networks and IP addresses" if you have currently selected "Disable public access".
The next step is to update the Azure App Service configuration to match the subject name of the intermediate CA you will create in the next step.
Navigate to your Azure App Service
Click on Environment variables in the left navigation pane
In Application settings, you must edit the following settings:
AppConfig:KeyVaultConfig:RootCertificateConfig:CertificateName
Change this to a preferred common name (CN) for your intermediate CA.
AppConfig:KeyVaultConfig:RootCertificateConfig:Subject
Only change the CN value of the subject name to match the common name used above.
Click on Apply and Confirm.
Restart the Azure App Service to apply the changes then navigate to your SCEPman URL.
Please be aware that the CertificateName variable will directly correspond to the certificate object that will be created in the Azure Key Vault. You can therefore only use certificate names that contain alphanumeric characters and dashes
You can use the SCEPman PowerShell module version 1.9 and later to create a CSR for an Intermediate CA certificate. You can install the latest version of the module from PowerShell Gallery with the following command:
Then, you can tell the module the name of your organization to appear in the certificate:
Configure the subject of your intermediate CA to match the one you have used above in AppConfig:KeyVaultConfig:RootCertificateConfig:Subject (optionally, you can modify some additional settings to control the CSR content):
Finally, you can create the CSR with the following command (or a similar one according to your environment):
The command will output the CSR that you submit to your Root CA for signing.
Now, submit your CSR to your Root CA and retrieve your issued Intermediate CA Certificate. Save the certificate on disk (.cer), so in the next step, you can upload and merge it with the private key in Azure Key Vault.
If you are using Active Directory Certificate Services as an AD-integrated Root CA and hence must choose a Certificate Template, it must include the following Key Usages: "CRLSign", "DigitalSignature", "KeyEncipherment", and "KeyCertSign". KeyEncipherment is missing in the default template "Subordinate Certificate Authority", and furthermore cannot be selected on new templates. Please see below for a solution if you run into this problem. This does not apply to Stand-alone Root CAs, aka Offline Root CAs, as they take the Key Usages correctly from the CSR.
You can Duplicate the SubCA Template or use it as required. Then you just issue a certificate with the template based on the CSR. This certificate will have the wrong Key Usage (0x86). Afterwards, you re-sign the certificate with an adapted Key Usage extension using certutil -sign.
Request and issue a SubCA certificate.
Export the new SubCA certificate to a file (e.g. c:\temp\SubCA.cer) on the Root CA. Choose Base-64 encoded X.509 format.
Create a file "extfile.txt" with the contents shown below to the Root CA (e.g. c:\temp\extfile.txt).
Start command line and execute: certutil -sign "c:\temp\SubCA.cer" "c:\temp\SubCAwithKeyEncipher.cer" @c:\temp\extfile.txt
The certificate SubCAwithKeyEncipher.cer now contains the requested key usage (0xA6). The thumbprint (signature) has changed, but the serial number hasn't.
The list of issued certificates in ADCS contains the old certificate. Since the serial number hasn't changed, you can manage the new certificate using the old handle, e.g. revoking the old certificate will revoke the new certificate. If you dislike this, you can delete the old certificate entry using certutil -deleterow and then import the new certificate using certutil -importcert.
In Azure Key Vault, click on your certificate and press Certificate Operation
Now you can see the options Download CSR and Merge Signed Request
Click on Merge Signed Request and upload your Intermediate CA Certificate. After you have uploaded the signed request, you can see the valid certificate in your Azure Key Vault in the area Completed
The Intermediate CA Certificate must be in PEM format (Base64-encoded). If you use the binary DER format, you will see an error message that says "Property x5c has invalid value X5C must have at least one valid item" in the details.
On the SCEPman Status page, you can see the new configuration and download the new intermediate CA certificate to deploy this via Endpoint Manager.
On the Android platform, the SCEP Configuration Profiles in Intune must reference the Root CA, not the Intermediate CA. Otherwise, the configuration profile fails. For Windows, it is the other way around: The SCEP Configuration Profiles in Intune must reference the Intermediate CA, not the Root CA. For iOS and macOS, we have no conclusive information whether one or the other way is better.
If you are using a for Key Vault, you need to add an exception that allows the client to access the Key Vault on a network level. If you are not using a Private Endpoint, you can skip this part.
Add the IP address of the client on which you want to . If you are using the Azure Cloud Shell and , you can add this VNET. Otherwise, the easiest way is to temporarily allow the Cloud Shell's Public IP address, since strong authentication protects your Key Vault. You might use a command like (Invoke-WebRequest -UseBasicParsing -uri "http://ifconfig.me/ip").Content to find the session's public IP address.
To ensure this module functions correctly, you will need a workstation with (also known as az) installed. The Azure CLI is pre-installed in the , which is the recommended environment for running this module.
Please check whether the CA certificate fulfills all requirements by visiting your SCEPman Homepage. Check what the homepage says next to "CA Suitability". If, for example, it says CA Certificate is missing Key Usage "Key Encipherment", you should go back to step and correct the certificate issuance.
