# SCEPman Documentation Cloud PKI & Certificate Management for Microsoft Intune and other MDMs ## Overview SCEPman is a slim and resource-friendly solution to issue and validate certificates using Simple Certificate Enrollment Protocol (SCEP). **It is an Azure Web App providing the SCEP protocol and works directly with the Microsoft Graph and Intune API.** SCEPman uses an Azure Key Vault based Root CA and certificate creation. By default, no other component is involved, neither a database nor any other stateful storage, except the Azure Key Vault itself. That said, SCEPman **will not need any backup procedures** or other operation level tasks. Only an Azure subscription is necessary to deploy it. SCEPman gives you control over how and where data is processed and stored. Depending on the deployment model, SCEPman can run either within **your Azure tenant** or as a **managed SaaS offering**. No external vendor permissions in your tenant are required. ![SCEP flow with Microsoft Intune](/files/dJ6BzTeaStHSTKyrYqv4) The following documentation will show you a straightforward way to deploy certificates to modern cloud managed clients. Without any on-premises PKI your users and devices will be able to get certificates. ## SCEPman vs. Legacy PKI If you are interested in learning more about the effort involved in installing and operating a legacy/on-premises PKI such as the Certificate Connector for Intune / Active Directory Certificate Services (ADCS) in comparison to SCEPman, please refer to the article below. {% content-ref url="/pages/rHw3GyxuBV1LBeNJzGgB" %} [Certificate Connector](/other/faqs/certificate-connector) {% endcontent-ref %} ## Get more details about SCEPman {% embed url="" %} SCEPman 2.0 - What's new? {% endembed %} {% content-ref url="/pages/-MCkO9Ams-RVsF2Cr84r" %} [Overview](/overview) {% endcontent-ref %} {% content-ref url="/pages/-MCkO9AnDlnFJOWQyTFL" %} [Editions](/editions) {% endcontent-ref %} ## SCEPman Guides We offer two guides to deploy the SCEPman environment. Please follow the link below for guidance on which guide is best suited for your scenario and deployment requirements: {% content-ref url="/pages/K72fpTZcpCv2dzmdnOdW" %} [Getting Started](/scepman-deployment/deployment-guides) {% endcontent-ref %} ## Change Log News from our development and our roadmap can be found under the **Change Log**. {% content-ref url="/pages/-MCkO9BJMLjpEydg5qBC" %} [Change Log](/changelog) {% endcontent-ref %} # Overview ## What is SCEP? Usually when it is necessary to deploy certificates to (mobile) devices, [Simple Certificate Enrollment Protocol](https://www.rfc-editor.org/rfc/rfc8894.html) (SCEP) is the first choice. But what is SCEP? SCEP is an [Internet draft](https://en.wikipedia.org/wiki/Internet_Draft) standard protocol. An Internet draft contains technical specifications and technical information. Internet drafts are often published as a [Request for Comments](https://en.wikipedia.org/wiki/Request_for_Comments). SCEP is originally developed by Cisco. The core mission of SCEP is the deployment of certificates to network devices without any user interactions. With the help of SCEP, network devices can request certificates on their own. ## What is SCEPman? If you use SCEP in a 'traditional way' you need a number of on-premises components. Microsoft Intune and [other Mobile Device Management (MDM)](/use-cases#mdm-solutions) solutions [allow third-party certificate authorities (CA](https://learn.microsoft.com/en-us/mem/intune/protect/certificate-authority-add-scep-overview)) to issue and validate certificates using SCEP. To get rid of the on-premises components we developed SCEPman. {% hint style="warning" %} SCEPman issues certificates that are **intended for authentication and transport encryption**. That said, you can deploy user and device certificates used for network authentication, WiFi, VPN, RADIUS and similar services. **You may** use SCEPman for transactional **digital signatures** i.e. for S/MIME signing in Microsoft Outlook. If you plan to use the certificates for message signing you need to add the corresponding extended key usages in the Intune profile configuration. Please keep in mind that SCEPman certificates are trusted in your organization only. SCEPman does not issue publicly trusted certificates. **Do not** use SCEPman **for email-encryption** i.e. for S/MIME mail encryption in Microsoft Outlook (without a separate technology for key management). The nature of **the SCEP protocol does not include a mechanism to backup or archive private key material.** If you would use SCEP for email-encryption you may lose the keys to decrypt the messages at a later time. {% endhint %} ### SCEPman Workflow Here's an overview about the SCEPman workflow when using Intune as MDM solution (the flows are similar for other MDM solutions). The first figure shows the certificate issuance and the second figure shows the certificate validation. Process of certificate issuance: ![](/files/o4b3HHJKbR9ifMwnga7L) Process of certificate validation during certificate-based authentication: ![](/files/J5gsMj90BCCIKMAZOH0D) ### SCEPman Features SCEPman is an Azure Web App with the following features: * A SCEP interface that is compatible with the Intune [SCEP API](https://learn.microsoft.com/en-us/mem/intune/protect/certificate-authority-add-scep-overview) in particular. * SCEPman provides certificates signed by a CA root key stored in **Azure Key Vault**. * SCEPman contains an **OCSP responder** (see below) to provide [certificate validity / auto-revocation](/certificate-management/manage-certificates#automatic-revocation) in real-time * A full replacement of Legacy PKI in many scenarios. SCEPman creates the CA root certificate during the initial installation. However, if for whatever reason an alternative CA key material shall be used it is possible to replace this CA key and certificate with your own in Azure Key Vault. For example, if you want to use a Sub CA certificate signed by an existing internal Root CA. #### Certificate Master Certificate Master allows [Enterprise Edition](/editions#edition-comparison) customers to (manually) issue certificates in scenarios where an automatic enrollment via SCEP / MDM is not possible. Common examples are the issuance of [TLS server certificates](/certificate-management/certificate-master/tls-server-certificate-pkcs-12) or user certificates for [smart cards / YubiKeys](/certificate-management/certificate-master/user-certificate). Furthermore, with Certificate Master, administrators can [manage](/certificate-management/manage-certificates) any certificate issued by SCEPman, whether they were automatically enrolled through SCEP via Intune, Jamf and other MDMs, EST, the [Enrollment REST API](/certificate-management/api-certificates) or manually via Certificate Master UI itself. {% content-ref url="/pages/hmGaPS9UcwHhyv2NA19Z" %} [Certificate Master](/certificate-management/certificate-master) {% endcontent-ref %} ### SCEPman OCSP (Online Certificate Status Protocol) The [Online Certificate Status Protocol (OCSP)](https://en.wikipedia.org/wiki/Online_Certificate_Status_Protocol) is an Internet protocol which is in use to determine the state of a certificate. Usually, an OCSP client sends a status request to an OCSP responder. An OCSP responder verifies the validity of a certificate based on revocation state or other mechanisms. In comparison to a certificate revocation list (CRL), that SCEPman supports as well, an OCSP response is always up-to-date and the response is available within seconds. A CRL has the disadvantage that it is based on a database that must refresh manually and may weigh a lot of data. Read a detailed comparison of these revocations mechanisms[ in an article in our company blog.](https://www.glueckkanja.com/blog/products/2023/05/certificate-revocation-en/) ## Getting Started Please follow the steps on the following page to deploy SCEPman and automate certificate issuance for users, devices, and network authentication scenarios. # Editions ## Overview We offer two different SCEPman editions: * Enterprise Edition * Community Edition Both editions use the same codebase and binaries. A Community Edition can be converted to an Enterprise Edition just by inserting a SCEPman license key (and maybe doing some additional config work). ## Enterprise Edition (SCEPman EE) SCEPman EE comes with all features and is supported by our team. We charge a subscription fee for SCEPman EE. We recommend SCEPman EE for: * Productive environments * Scalability and performance * Enterprise feature set {% content-ref url="/pages/Q8OHVYcgZu90KjaVMffm" %} [Licensing](/other/licensing) {% endcontent-ref %} ## Community Edition (SCEPman CE) SCEPman CE misses some features of SCEPman EE and is not supported by our team. SCEPman CE is free of charge. We recommend SCEPman CE for: * Lab environments * Small businesses * Easy testing of SCEPman If you want to test SCEPman in your own environment, you can follow the **mandatory** steps in our [Standard Guide](/scepman-deployment/deployment-guides/community-guide) and install SCEPman directly into your lab. If you later decide to purchase SCEPman EE, you should review our Getting Started guide [decision matrix](/scepman-deployment/deployment-guides#decision-matrix) and revisit all **recommended** and **optional** steps. {% hint style="info" %} If your organization has Azure resource naming conventions in place and you intend to re-use the Community Edition deployment after a successful trial, please directly start with our [Extended Guide](/scepman-deployment/deployment-guides/enterprise-guide-1) (**mandatory** steps only). For the basic steps, no license key is required. {% endhint %} ## Edition Comparison The following table shows the most important differences between the two editions:
SCEPman FeatureCommunity EditionEnterprise Edition
Machine certificates for Intune- or Jamf Pro-managed devices
(Windows 11, MacOS, Android, iOS)		yesyes
User certificates on Intune- or Jamf Pro-managed devices
(Windows 11, MacOS, Android, iOS)		yesyes
Machine and user certificats for Active Directory / GPO managed (domain-joined) devices (Windows 10/11)noyes
Certificate management, manually issue & revoke certificates,
e.g. for web servers		noyes

Kerberos authentication certificates for DCs

(Access on-prem ressources and use
Windows Hello for Business with Entra ID/Hybrid-joined devices)

noyes
Certificates for other MDM-systems with Entra ID validation.noyes
Redundancynoyes
SCEPman as intermediate CAnoyes
Device Compliance Checknoyes
Supportnoincluded
Feefreesubscription-fee
# RADIUSaaS Integration SCEPman integrates seamlessly with [RADIUSaaS](https://docs.radiusaas.com/?_gl=1*1qkd9on*_ga*MTY4NjA4MjY0NS4xNzgzNDA2ODEx*_ga_5D8Y8TBBDJ*czE3ODM0MDY4MTAkbzEkZzAkdDE3ODM0MDY4MTAkajYwJGwwJGgw) to provide a complete certificate-based authentication solution for Wi-Fi, VPN, and wired network access. Together, both products enable organizations to deploy passwordless network authentication using certificates issued by SCEPman and validated by RADIUSaaS. Customers can choose between a self-managed Enterprise Bundle or a fully managed SaaS Bundle depending on their operational and compliance requirements. **The following bundle options are available:** ## **RADIUSaaS + SCEPman Enterprise Bundle** The RADIUSaaS + SCEPman Enterprise Bundle combines the full Enterprise Editions of SCEPman and RADIUSaaS into one integrated solution for certificate-based network access. The bundle includes all enterprise features, product support, and advanced authentication capabilities required for productive environments. It is designed for organizations that want to secure Wi-Fi, VPN, and wired network access using certificates without relying on traditional passwords. **We recommend the Enterprise Bundle for:** * Productive environments * Enterprise-grade network security * Certificate-based Wi-Fi, VPN, and LAN authentication * Scalability and high availability * Organizations requiring support and enterprise features ## **RADIUSaaS + SCEPman SaaS Bundle** The RADIUSaaS + SCEPman SaaS Bundle provides a fully managed cloud-based solution for certificate issuance and network authentication. By combining SCEPman and RADIUSaaS in a SaaS offering, organizations can deploy secure network access without managing their own PKI or RADIUS infrastructure. The solution integrates with Microsoft Intune and Microsoft Entra ID to enable modern, passwordless network authentication. **We recommend the SaaS Bundle for:** * Organizations looking for a fully managed service * Simplified deployment and operations * Cloud-first environments * Certificate-based Wi-Fi and VPN authentication * Reduced infrastructure and maintenance effort For both options the [SCEPman Connection](https://docs.radiusaas.com/admin-portal/settings/settings-server#scepman-connection) feature enables automatic issuance and renewal of RADIUSaaS server certificates through SCEPman. ## **RADIUSaaS + SCEPman Bundle Edition Comparison**
CapabilityRADIUSaaS + SCEPman Enterprise BundleRADIUSaaS + SCEPman SaaS Bundle
HostingCustomer's Azure TenantVendor's Datacenters
Infrastructure CostCustomerVendor
MaintenanceCustomer / AzureVendor
ConfigurationCustomerCustomer
Geo-RedundancyYesPlanned
Certificate Master RBACYesNo
AD EnrollmentYesPlanned
Enrollment REST APIYesPlanned
LoggingAzure Monitor /
Log Analytics		WebConsole
CA hierarchyYesBring your own Key Vault (BYOK)
Machine certificatesYesYes
User certificatesYesYes
AD Device CertificatesYesYes
Certificate ManagementYesYes
Kerberos CertificatesYesPlanned
Other MDM IntegrationYesYes
Device Compliance CheckYesYes
SupportYesYes
Licensing Subscription-fee Subscription-fee
For licensing, purchasing, and trial options, visit the [RADIUSaaS + SCEPman Bundle website](https://www.scepman.com/secure-network-access-bundle). # Use Cases This page is intended to give you an **overview** of **common use cases** and scenarios our clients leverage SCEPman for. While we cannot provide support for the intricacies of every vendor solution, we hope this overview helps you to quickly assess whether SCEPman could be a fit for your scenario, too - without overwhelming you with less common or even exotic use-cases. If you are unsure, just [drop us a question](https://www.scepman.com/drop-a-question). ## Secure WiFi and Network Access Certificates issued by SCEPman are widely used for the purpose of certificate-based network authentication (802.1X / EAP-TLS) for WiFi, Wired/LAN and VPN, typically along with a network access control (NAC) service that speaks the RADIUS or RadSec protocol. Such services commonly are * [RADIUSaaS](https://www.radius-as-a-service.com/) * Aruba ClearPass * Cisco ISE / Cisco ASA * Azure VPN Gateway / Azure AlwaysOn VPN * Fortinet FortiGate * Palo Alto GlobalProtect In addition to typical user-centric client devices such as laptops, PCs or Macs, **kiosk devices** such as point of sales or self-checkout systems, scanner/barcode guns or customer terminals are often equipped with certificates from SCEPman for secure network authentication. ## Certificate-based Authentication You can enrol user authentication certificates with SCEPman for TLS client authentication. This allows authentication to web sites or services such as * Internal web applications * [Windows](/certificate-management/api-certificates/api-enrollment/windows-server) or [Linux](/certificate-management/api-certificates/api-enrollment/linux-server) servers * Microsoft 365 * Exchange Online * Azure Active Directory (AAD) / Azure CBA (including [CRL support](/scepman-configuration/application-settings/crl)) as, e.g. required by [NIST 800-63, Rev. 4](https://www.nist.gov/identity-access-management/roadmap-nist-special-publication-800-63-4-digital-identity-guidelines) * Other cloud services * Remote Desktop (RDP) connections * AVD * Windows server administration / PAWs ## TLS Inspection SCEPman can [issue sub CA certificates](/certificate-management/certificate-master/sub-ca-certificate) for TLS inspection on firewall appliances and services such as * [Azure Firewall](https://learn.microsoft.com/en-us/azure/firewall/premium-certificates) * Global Secure Access (GSA) ([Microsoft Entra Internet Access](https://learn.microsoft.com/en-us/entra/global-secure-access/how-to-transport-layer-security)) * Other firewall appliances ## MDM Solutions To automate the deployment of relevant configuration profiles and to keep certificates up to date (auto-renewal), we recommend to use SCEPman along with an MDM solution. While SCEPman natively integrates with Microsoft Endpoint Manager/Intune and Jamf Pro, our customers have successfully deployed SCEPman along with other MDM solutions. Below table provides an overview of the most commonly used MDM solutions and indicates how/if certificate revocation is possible. | MDM Solution | Supported Platforms | Issuance & Auto-renewal | Automatic Revocation | Manual Revocation | Links | | --------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------- | -------------------------------------------- | ---------------------------- | ---------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | |

Intune /
Endpoint Manager

|

Windows
macOS
iOS

iPadOS
Android
Linux

| :ballot\_box\_with\_check: | :ballot\_box\_with\_check: |

☑️

| [Microsoft Docs](https://docs.microsoft.com/en-us/mem/intune/protect/certificates-profile-scep) | | [Active Directory / Group Policy (GPO)](/certificate-management/active-directory) | Windows | :ballot\_box\_with\_check: | | | | | [Jamf Pro](/certificate-management/jamf) |

macOS
iOS
iPadOS

| :ballot\_box\_with\_check: | :ballot\_box\_with\_check: | :ballot\_box\_with\_check: | [Jamf Technical Paper](https://docs.jamf.com/technical-papers/jamf-pro/scep-proxy/10.0.0/Introduction.html) | | [GSuite / Google Workspace](/certificate-management/static-certificates) |

ChromeOS
Android

| :ballot\_box\_with\_check: | :ballot\_box\_with\_check:\* | :ballot\_box\_with\_check: | [Google Support Docs](https://support.google.com/chrome/a/answer/11053129?hl=en) | | [Airwatch / WorkspaceONE UEM](/certificate-management/static-certificates) |

macOS
iOS

| :ballot\_box\_with\_check: (no auto-renewal) | | :ballot\_box\_with\_check: | [VMware Support Docs](https://docs.vmware.com/en/VMware-Workspace-ONE-UEM/2011/Certificate_Authority_Integrations/GUID-EF7C4D44-9480-4AD1-91E3-EA4F02448F5A.html) | | [Mosyle](/certificate-management/static-certificates/mosyle) |

macOS

iOS
iPadOS

| :ballot\_box\_with\_check: | | :ballot\_box\_with\_check: | | | [SOTI MobiControl](/certificate-management/static-certificates) |

Windows
macOS
iOS

iPadOS
Android
Ubuntu

| :ballot\_box\_with\_check: | | :ballot\_box\_with\_check: |

Soti Docs - External CA
Soti Docs - SCEP Profile

| | [Kandji](/certificate-management/static-certificates/kandji-1) |

macOS
iOS
iPadOS

| :ballot\_box\_with\_check: | :ballot\_box\_with\_check:\* | :ballot\_box\_with\_check: | [Kandji Docs](https://support.kandji.io/support/solutions/articles/72000559782-scep-profile) | | [ManageEngine](/certificate-management/static-certificates) |

Windows
macOS
iOS

iPadOS
Android

| :ballot\_box\_with\_check: | | :ballot\_box\_with\_check: | [ManageEngine Docs](https://www.manageengine.com/mobile-device-management/help/certificate_management/mdm_integrating_generic_scep.html) | \*: Only works with user-type certificates if the user-objects are synced from Microsoft Entra ID (Azure AD). ## On-premises to Cloud Migration Since SCEPman is a cloud-native and general purpose PKI, many of our clients who migrate their on-premises infrastructure to the cloud, use SCEPman to fully replace their on-premises Microsoft PKI (ADCS and NDES). With SCEPman, this is possible for endpoint devices that are * Domain-joined, * Hybrid-joined, or * Entra ID-joined. ## IoT Devices SCEPman can be utilized to supply certificates to IoT devices. Therefore, SCEPman supports an ECC CA allowing performance- and energy-optimized cryptographic algorithms on devices with limited computational resources or on devices relying on battery power. SCEPman's flexibility supports issuing certificates with long validity periods allowing a long-term offline operation without the need to renew certificates regularly. Furthermore, certificates can be enrolled on an assembly line in a convenient way by leveraging SCEPman's REST API with Microsoft Entra ID (Azure AD)-based authentication. # Getting Started In order to get started with SCEPman, we have prepared two guides that address different requirements and scopes for your deployment scenario. **Please use the table below**, to decide which of the two guides is best suited for your scenario. ## Decision Matrix {% hint style="info" %} In case you have Azure resource naming conventions, high availability or auto-scaling requirements that you'd also like to trial, please directly start with **Extended Guide** - even for your Trial/PoC. This will allow you to re-use the deployment in production later on. {% endhint %} | Requirement / Scope | Standard Guide | Extended Guide | | ------------------------------------------------------------------ | :--------------------------------------------------------------------------------------------------------------------------: | :------------------------: | | I am using SCEPman Community Edition |

☑️

(not all features available)

| | | Trial or PoC |

☑️

(only mandatory steps)

| | | Standard production deployment | :ballot\_box\_with\_check: | | | I must obey Azure resource naming conventions | | :ballot\_box\_with\_check: | | High-availability / redundancy | | :ballot\_box\_with\_check: | | Auto-scaling | | :ballot\_box\_with\_check: | | Terraform deployment | | :ballot\_box\_with\_check: | | I am in an Azure Government cloud region (GCC High, 21Vianet, ...) | | :ballot\_box\_with\_check: | {% content-ref url="/pages/-MCkO9ArLbD8DrG2gtYE" %} [Standard Guide](/scepman-deployment/deployment-guides/community-guide) {% endcontent-ref %} {% content-ref url="/pages/RP5p18FAMtQi3IXCEc3K" %} [Extended Guide](/scepman-deployment/deployment-guides/enterprise-guide-1) {% endcontent-ref %} ## Videos {% embed url="" %} SCEPman 2.0 Deployment {% endembed %} ## Scenarios For configuration examples of specific scenarios that involve SCEPman-issued certificates, please refer to the following section: {% content-ref url="/pages/Hy3RCogixxrZxFRdYVzz" %} [Scenarios](/scepman-deployment/deployment-guides/scenarios) {% endcontent-ref %} # Standard Guide This will guide you through all steps necessary to set up SCEPman in your PoC or Production environment based on our best practices. ## Azure Deployment Let's start with the requirements and a resource overview.\ Keep in mind that you need to plan a useful Azure resource design. ### Prerequisites #### Mandatory * [ ] Azure subscription (at least Contributor rights on that subscription). * [ ] Azure owner rights (at least on Resource Group level). * [ ] Microsoft Entra ID (Azure AD) "Global administrator" (Consent to access Graph API). * [ ] Make sure to define your Azure policies [according to SCEPman requirements](/other/security-faq#azure-cis) (e.g. do not enforce TLS). #### Optional * [ ] Public Domain CNAME (scepman.yourdomain.com), if a custom domain is used. * [ ] SSL (Wildcard-) Certificate (or use [App Service Managed Certificate](https://docs.microsoft.com/en-us/azure/app-service/configure-ssl-certificate#create-a-free-certificate-preview)), if a custom domain is used. ### Overview Azure Resource All these resources are recommended for a production environment. | Type | Description | | ----------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | App Service (x2) |

A virtual Azure environment to run the SCEPman Core and Cert Master applications and provides a UI to configure different
application specific settings like CNAME, SSL certificate and App Settings.

| | App Service Plan |

A virtual set of compute resources and configurations for the "App Service(s)".

Here you can configure the pricing tier and resource scaling.

| | Key Vault | Tool to securely store secrets and certificates. The SCEPman application will generate and save the root certificate in your Key Vault. | | Application Insights | Application Performance Management (APM) tool to get insights of the SCEPman applications and requests. Needed to measure performance and good for service optimization. | | Storage account |

Storage platform used by SCEPman's Certificate Master component to store certificates attributes for revocation purposes.

Optional:

The "App Service" will load the artifacts from a blob storage URI if manual updates are configured.

| | Log Analytics workspace |

A centralized and cloud-based log storage. The "App Service" will save all

platform logs and metrics into this workspace.

Since v3.0, SCEPman writes logs to the Log Analytics Workspace using Microsoft's Log Ingestion API.

| Additionally, if you are using Private Endpoints, you have [seven more Azure Resources.](/azure-configuration/private-endpoints#azure-resources-used-for-private-endpoints)
TypeDescription
Virtual NetworkThe SCEPman App Services, the Key Vault, and the Storage Account connect over this VNET.
Private Endpoint (×2)One for the Key Vault and one for the Storage Account. It makes them accessible over the VNET.
Private DNS zone (×2)One for the Key Vault and one for the Storage Account. They both have an internal IP address in the VNET, for which they have a name in their respective Private DNS zone.
Network Interface (×2)One for the Key Vault and one for the Storage Account. It connects the Private Endpoint to the VNET.
## Configuration Steps {% stepper %} {% step %} ### Deploy SCEPman Base Services {% hint style="warning" %} This is a **mandatory** step. {% endhint %} To start with the deployment, please follow our deployment instructions: {% content-ref url="/pages/-MCkO9Ax5vQDsk6iokZq" %} [Marketplace deployment](/scepman-deployment/deployment-options/marketplace-deployment) {% endcontent-ref %} {% endstep %} {% step %} ### Perform Post-Deployment Steps (Permission Assignments) {% hint style="warning" %} This is a **mandatory** step. {% endhint %} To properly link all components of SCEPman, several permissions need to be assigned. Please follow these steps to establish the relevant connections: {% content-ref url="/pages/8WU2d52tz1E751TB5wn2" %} [Managed Identities](/scepman-deployment/permissions/post-installation-config) {% endcontent-ref %} {% endstep %} {% step %} ### Add Certificate Master Permissions {% hint style="success" %} This is a **mandatory** step for **Enterprise** **Edition** customers. **Community Edition** users may skip this step. {% endhint %} The Certificate Master is an **Enterprise Edition** feature that allows administrators to manually generate and revoke certificates. Please follow these steps to provide access to the Certificate Master. {% content-ref url="/pages/YCeg2omWp8sx2tlT8hd4" %} [Certificate Master RBAC](/scepman-configuration/rbac) {% endcontent-ref %} {% endstep %} {% step %} ### Create Root certificate {% hint style="warning" %} This is a **mandatory** step. {% endhint %} After the deployment and permission assignment is complete, you need to create the root certificate for SCEPman: {% content-ref url="/pages/-MR4iltnRly635vpZAY2" %} [Root CA](/scepman-deployment/first-run-root-cert) {% endcontent-ref %} {% endstep %} {% step %} ### Configure a Custom Domain and SSL Certificate {% hint style="info" %} This is an **optional** step. {% endhint %} To have your SCEPman available under your specific domain you need to create a **Custom Domain** in the **App Service.** {% content-ref url="/pages/JJWmkIqLTr0mMGfbt5Ly" %} [Custom Domain](/azure-configuration/custom-domain) {% endcontent-ref %} {% endstep %} {% step %} ### Manual Updates {% hint style="info" %} This is an **optional** step. {% endhint %} By default, SCEPman adopts an [evergreen approach](/azure-configuration/update-strategy#evergreen-approach) towards updates. In case you require full control over your SCEPman updates, please configure a deployment slot as described in the following guide under section **Deployment Slot Configuration**. {% content-ref url="/pages/YdA5aXwMLA3hSTZNYES9" %} [Update Strategy](/azure-configuration/update-strategy) {% endcontent-ref %} {% endstep %} {% step %} ### Deploy Application Insights {% hint style="success" %} This is **recommended** step. {% endhint %} The Application Insights can be used to get an overview of the App Service performance and to get deeper insights of the request processing of SCEPman. We recommend to always configure Application Insights to monitor, maintain and optimize the App Service. {% content-ref url="/pages/k6x52AQaz7sT8QXplDzl" %} [Application Insights](/azure-configuration/application-insights) {% endcontent-ref %} {% endstep %} {% step %} ### Configure Health Check {% hint style="success" %} This is **recommended** step. {% endhint %} We can configure a Health Check for the App Service to get direct notifications in case that the SCEPman stops working. {% content-ref url="/pages/tFsgPuXD0a2C2RZXsGNI" %} [Health Check](/azure-configuration/health-check) {% endcontent-ref %} {% endstep %} {% step %} ### Ensure that SCEPman has sufficient Resources {% hint style="warning" %} This is a **mandatory** step. {% endhint %} Once you move SCEPman into a production environment, you should ensure that SCEPman is equipped with sufficient computing power. Therefore, please review our Azure Sizing guide and upgrade your App Service Plan tier if need be. You may postpone this until after your PoC or trial phase. {% content-ref url="/pages/ROQrYA83dZwfEAVmNsTN" %} [App Service Sizing](/azure-configuration/azure-sizing) {% endcontent-ref %} {% endstep %} {% step %} ### Configure your MDM Deployment Profiles {% hint style="success" %} This is a **recommended** step. {% endhint %} With the completion of the above steps, we have a working SCEPman implementation and can now deploy certificates to the devices. Please use one (or more) of the following articles, to deploy certificates with your preferred MDM solution: {% content-ref url="/pages/-MROXwTHsanePl1clXAC" %} [Microsoft Intune](/certificate-management/microsoft-intune) {% endcontent-ref %} {% content-ref url="/pages/-MZCl0wDeDmzYco7v-8W" %} [Jamf Pro](/certificate-management/jamf) {% endcontent-ref %} {% content-ref url="/pages/-MNNk--1YwV7JnJlOyEx" %} [Other MDM Solutions](/certificate-management/static-certificates) {% endcontent-ref %} {% endstep %} {% step %} ### Manually Issue Certificates or sign CSRs using the Certificate Master {% hint style="info" %} This is an **optional** step. {% endhint %} Please follow below link, to learn how to issue TLS server or other certificates or how to sign any CSR using the Certificate Master component. {% content-ref url="/pages/hmGaPS9UcwHhyv2NA19Z" %} [Certificate Master](/certificate-management/certificate-master) {% endcontent-ref %} {% endstep %} {% endstepper %} # Extended Guide {% hint style="warning" %} SCEPman Enterprise Edition only {% endhint %} This will guide you through all steps to deploy SCEPman for an enterprise-grade environment with advanced requirements, e.g. naming conventions, redundancy or auto-scaling. ## Azure Deployment Let's start with the requirements and a resource overview.\ Keep in mind that you need to plan a useful Azure resource design. ### Prerequisites #### Mandatory * [ ] Azure resource naming convention. * [ ] Azure subscription (at least Contributor rights on that subscription). * [ ] Azure owner rights (at least on Resource Group level). * [ ] Microsoft Entra ID (Azure AD) "Global administrator" (Consent to access Graph API). * [ ] Make sure to define your Azure policies [according to SCEPman requirements](/other/security-faq#azure-cis) (e.g. do not enforce TLS). * [ ] Public Domain CNAME (*scepman.yourdomain.com*), only if geo-redundancy is used. * [ ] SSL Certificate (or use [App Service Managed Certificate](https://docs.microsoft.com/en-us/azure/app-service/configure-ssl-certificate#create-a-free-certificate-preview)), only if geo-redundancy is used. * [ ] SCEPman Enterprise Edition License Key. #### Optional * [ ] Public Domain CNAME (*scepman.yourdomain.com*), only if a custom domain is used. * [ ] SSL (Wildcard-) Certificate (or use [App Service Managed Certificate](https://docs.microsoft.com/en-us/azure/app-service/configure-ssl-certificate#create-a-free-certificate-preview)), only if a custom domain is used. ### Azure Resource Overview The following resources are recommended for a production environment. | Type | Description | | ----------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | App Service (x2) |

A virtual Azure environment to run the SCEPman Core and Cert Master applications and provides a UI to configure different
application specific settings like CNAME, SSL certificate and App Settings.

| | App Service Plan |

A virtual set of compute resources and configurations for the "App Service(s)".

Here you can configure the pricing tier and resource scaling.

| | Key Vault | Tool to securely store secrets and certificates. The SCEPman application will generate and save the root certificate in your Key Vault. | | Application Insights | Application Performance Management (APM) tool to get insights of the SCEPman applications and requests. Needed to measure performance and good for service optimization. | | Storage account |

Storage platform used by SCEPman's Certificate Master component to store certificates attributes for revocation purposes.

Optional:

The "App Service" will load the artifacts from a blob storage URI if manual updates are configured.

| | Log Analytics workspace |

A centralized and cloud-based log storage. The "App Service" will save all

platform logs and metrics into this workspace.

Since v3.0, SCEPman writes logs to the Log Analytics Workspace using Microsoft's Log Ingestion API.

| Additionally, if you are using Private Endpoints, you have [seven additional Azure resources.](/azure-configuration/private-endpoints#azure-resources-used-for-private-endpoints)
TypeDescription
Virtual NetworkThe SCEPman App Services, the Key Vault, and the Storage Account connect over this VNET.
Private Endpoint (×2)One for the Key Vault and one for the Storage Account. It makes them accessible over the VNET.
Private DNS zone (×2)One for the Key Vault and one for the Storage Account. They both have an internal IP address in the VNET, for which they have a name in their respective Private DNS zone.
Network Interface (×2)One for the Key Vault and one for the Storage Account. It connects the Private Endpoint to the VNET.
## Configuration Steps {% stepper %} {% step %} ### Deploy SCEPman Base Services {% hint style="warning" %} This is a **mandatory** step. {% endhint %} Make your choice on whether you'd like to deploy with a **Windows** or **Linux** App Service Plan. Both deployment methods will allow you to choose your Operating System. To start with the deployment, you need to follow our setup instructions leveraging an **ARM Template** {% content-ref url="/pages/-MCkO9AyXaqifRD7KuiV" %} [Enterprise deployment](/scepman-deployment/deployment-options/enterprise-deployment) {% endcontent-ref %} or alternatively our **Terraform** script: {% content-ref url="/pages/2Rs4K4ETWZIl5EnDDTDW" %} [Terraform deployment](/scepman-deployment/deployment-options/terraform-deployment) {% endcontent-ref %} {% endstep %} {% step %} ### Perform Post-Deployment Steps (Permission Assignments) {% hint style="warning" %} This is a **mandatory** step. {% endhint %} To properly link all components of SCEPman, several permissions need to be assigned. Please follow these steps to establish the relevant connections: {% content-ref url="/pages/8WU2d52tz1E751TB5wn2" %} [Managed Identities](/scepman-deployment/permissions/post-installation-config) {% endcontent-ref %} {% endstep %} {% step %} ### Add Certificate Master Permissions {% hint style="success" %} This is a **mandatory** step for **Enterprise** **Edition** customers. **Community Edition** users may skip this step. {% endhint %} The Certificate Master is an **Enterprise Edition** feature that allows administrators to manually generate and revoke certificates. Please follow these steps to provide access to the Certificate Master. {% content-ref url="/pages/YCeg2omWp8sx2tlT8hd4" %} [Certificate Master RBAC](/scepman-configuration/rbac) {% endcontent-ref %} {% endstep %} {% step %} ### Create Root Certificate {% hint style="warning" %} This is a **mandatory** step. {% endhint %} After the deployment and permission assignment is complete, you need to create the root certificate for SCEPman: {% content-ref url="/pages/-MR4iltnRly635vpZAY2" %} [Root CA](/scepman-deployment/first-run-root-cert) {% endcontent-ref %} {% endstep %} {% step %} ### Configure a Custom Domain and SSL Certificate {% hint style="success" %} This is a **recommended** step. However, **skip** this step if you are implementing geo-redundancy. {% endhint %} To have your SCEPman available under your specific domain you need to create a **Custom Domain** in the **App Service.** {% content-ref url="/pages/JJWmkIqLTr0mMGfbt5Ly" %} [Custom Domain](/azure-configuration/custom-domain) {% endcontent-ref %} {% endstep %} {% step %} ### Manual Updates {% hint style="info" %} This is an **optional** step. {% endhint %} By default, SCEPman adopts an [evergreen approach](/azure-configuration/update-strategy#evergreen-approach) towards updates. In case you require full control over your SCEPman updates, please configure a deployment slot as described in the following guide under section **Deployment Slot Configuration**. {% content-ref url="/pages/YdA5aXwMLA3hSTZNYES9" %} [Update Strategy](/azure-configuration/update-strategy) {% endcontent-ref %} {% endstep %} {% step %} ### Deploy Application Insights {% hint style="success" %} This is **recommended** step. {% endhint %} The Application Insights can be used to get an overview of the App Service performance and to get deeper insights of the request processing of SCEPman. We recommend to always configure Application Insights to monitor, maintain and optimize the App Service. {% content-ref url="/pages/k6x52AQaz7sT8QXplDzl" %} [Application Insights](/azure-configuration/application-insights) {% endcontent-ref %} {% endstep %} {% step %} ### Configure Health Check {% hint style="success" %} This is **recommended** step. {% endhint %} Health Checks can be configured to notify administrators in the event the SCEPman App Service is unresponsive. {% content-ref url="/pages/tFsgPuXD0a2C2RZXsGNI" %} [Health Check](/azure-configuration/health-check) {% endcontent-ref %} {% endstep %} {% step %} ### Ensure that SCEPman has sufficient resources {% hint style="warning" %} This is a **mandatory** step. {% endhint %} Once you move SCEPman into a production environment, you should ensure that SCEPman is equipped with sufficient computing power. Therefore, please review our Azure Sizing guide and upgrade your App Service Plan tier if need be. You may postpone this until after your PoC or trial phase. {% content-ref url="/pages/ROQrYA83dZwfEAVmNsTN" %} [App Service Sizing](/azure-configuration/azure-sizing) {% endcontent-ref %} {% endstep %} {% step %} ### Configure Autoscaling {% hint style="info" %} This is an **optional** step. {% endhint %} The SCEPman solution has two different tasks and performance requirements.\ One task is the certificate issuance process: After the configuration of the SCEPman solution we need to deploy certificates to all devices (user and/or device certificates), but this is a one-time-task and after the initial deployment this only happens when a new device is enrolled, or the certificates needs to be renewed. In those situations, the SCEPman will face a peek of SCEP requests. The second task is the certificate validation: After we deployed certificates to devices, those certificates need to be validated each time we use them. For every certificated-based authentication the clients, gateways, or RADIUS system (depends on what you use) will send an OCSP request to the SCEPman App Service. This will cause a permanent request load on the App Service. To have an optimized performance and take care of the costs we recommend to setup the Autoscaling functionality of the App Service. With this feature your application can scale-out and scale-in based on metrics. {% content-ref url="/pages/TIJ26UKEHcAiNH5Eia8f" %} [Autoscaling](/azure-configuration/azure-sizing/autoscaling) {% endcontent-ref %} {% endstep %} {% step %} ### Configure Geo-Redundancy {% hint style="info" %} This is an **optional** step. {% endhint %} Configuring a geo-redundant instance for SCEPman can enhance service availability and resilience by distributing workloads across multiple Azure regions. However, it's important to note that this setup may lead to increased Azure costs due to the additional resources and data replication involved. Microsoft provides an SLA of 99.95% for Azure App Services, which is adequate in most scenarios. {% content-ref url="/pages/2RcnsphciwlJ0sdfgqvU" %} [Geo-Redundancy](/azure-configuration/geo-redundancy) {% endcontent-ref %} {% endstep %} {% step %} ### Configure your MDM Deployment Profiles {% hint style="success" %} This is a **recommended** step. {% endhint %} With the completion of the above steps, we have a working SCEPman implementation and can now deploy certificates to the devices. Please use one (or more) of the following articles, to deploy certificates with your preferred MDM solution: {% content-ref url="/pages/-MROXwTHsanePl1clXAC" %} [Microsoft Intune](/certificate-management/microsoft-intune) {% endcontent-ref %} {% content-ref url="/pages/-MZCl0wDeDmzYco7v-8W" %} [Jamf Pro](/certificate-management/jamf) {% endcontent-ref %} {% content-ref url="/pages/-MNNk--1YwV7JnJlOyEx" %} [Other MDM Solutions](/certificate-management/static-certificates) {% endcontent-ref %} {% endstep %} {% step %} ### Manually Issue Certificates or sign CSRs using the Certificate Master {% hint style="info" %} This is an **optional** step. {% endhint %} Please follow below link, to learn how to issue TLS server certificates based on a list of FQDNs or sign any CSR using the Certificate Master component. {% content-ref url="/pages/hmGaPS9UcwHhyv2NA19Z" %} [Certificate Master](/certificate-management/certificate-master) {% endcontent-ref %} {% endstep %} {% step %} ### Issue Certificates using the Enrollment REST API {% hint style="info" %} This is an **optional** step. {% endhint %} SCEPman features a REST API to enroll certificates. This is an alternative to the SCEP endpoints that require the SCEP-style of authentication, while the REST API uses Microsoft Identities for authentication. The protocol is also much simpler than SCEP. {% content-ref url="/pages/WRnOaOSvNON42tolL12D" %} [Enrollment REST API](/certificate-management/api-certificates) {% endcontent-ref %} {% endstep %} {% step %} ### Create Locks on SCEPman Azure resources {% hint style="info" %} This is an **optional** step. {% endhint %} By default, SCEPman does not apply any locks to Azure resources. If you use resource locks and wish to configure them, the following list outlines which lock types can be applied to each SCEPman resource. * **Key Vault:** Soft Delete and Purge Protection already provide protection against accidental deletion. SCEPman does not modify the resource after CA key creation, so a **ReadOnlyLock** is technically possible. * **Storage Account:** Only a **DeleteLock** is possible, as SCEPman needs to write certificate information into the table. If a Storage Account is accidentally deleted, you lose information about already issued certificates. * **App Services:** A **ReadOnlyLock** is theoretically possible, but it must be removed each time you modify the SCEPman configuration. A deleted App Service can easily be reinstalled, but it will only have the default configuration, so all manual changes must be reconfigured manually. A combination of **DeleteLock** and **ReadOnlyLock** helps mitigate this risk. * **Log Analytics Workspace:** A **DeleteLock** is technically possible, but you would only lose logs collected during the retention period, which does not impact the availability of the SCEPman service. * **Other Azure Resources:** These do not store data and can be recreated without loss of information. A **DeleteLock** and **ReadOnlyLock** can be useful for some of them. Some cannot be deleted at all because they have dependencies on one of the core services mentioned above. {% endstep %} {% endstepper %} # Scenarios # Certificate-based Network Authentication We recommend using our RADIUS-as-a-Service as Network Access Controller (NAC) to realize certificate-based WiFi, LAN, or VPN authentication, as it allows a one-click configuration. SCEPman certificates generally work with all NACs that support standard 802.1x certificate-based authentication, though. This article describes notable characteristics of some of the most common NACs. ## RADIUS-as-a-Service Please refer to the [RADIUS-as-a-Service documentation](https://docs.radiusaas.com/configuration/get-started/scenario-based-guides/scepman-pki) to see how to use SCEPman certificates in RADIUS-as-a-Service. ## Cisco ISE {% hint style="info" %} This is no longer required for Cisco * ISE Release 3.2 Patch 8 or later, * ISE Release 3.3 Patch 5 or later, * ISE Release 3.4 Patch 2 or later {% endhint %} Cisco ISE commonly does not support HTTP 1.1 but only HTTP 1.0 for OCSP requests. This requires an additional Application Proxy in front of SCEPman. Refer to our [Troubleshooting Article for ISE](/other/troubleshooting/cisco-ise-host-header-limitation) for details. At least some versions of Cisco ISE 3.x require an Extended Key Usage extension containing the OCSP Responder Extended Key Usage in order to accept OCSP responses, even if they come from a CA, where it is not required per RFC. SCEPman versions until 1.7 did not add an Extended Key Usage by default to its CA certificate. Version 1.8 allows you to add this extension via a [configuration setting](/scepman-configuration/application-settings/dependencies-azure-services/azure-keyvault#appconfig-keyvaultconfig-rootcertificateconfig-addextendedkeyusage). In SCEPman 1.9, the default of the configuration setting already adds the Extended Key Usage. If you already have a CA certificate without an Extended Key Usage extension and have issues with Cisco ISE 3.x, you may need to create a new SCEPman Root CA certificate with the Extended Key Usage extension. ## Aruba ClearPass ### Microsoft Intune ClearPass Extension In case you are using Aruba's [Microsoft Intune ClearPass Extension](https://arubanetworking.hpe.com/techdocs/NAC/clearpass/integrations/unified-endpoint-management/intune/) within the ClearPass Policy Manager, you are required to add the device IDs to the [SCEP certificate template](/certificate-management/microsoft-intune/windows-10#device-certificates) in a certain format. To ensure compatibility with SCEPman, below SAN attributes are required in the following **order**: * `(URI)` Value: `DeviceId:{{DeviceId}}` * `(URI)` Value: `AAD_Device_ID:{{AAD_Device_ID}}` * `(URI)` Value: `IntuneDeviceId://{{DeviceId}}` {% hint style="info" %} The first two entries are used by ClearPass, while the third entry is used by SCEPman. {% endhint %} ### OCSP HTTP 1.0 Issue {% hint style="info" %} This is **no longer required** for ClearPass 6.9.6 or later. {% endhint %} Analogously to Cisco ISE, Aruba ClearPass uses HTTP 1.0 for OCSP requests and therefore requires [extra configuration steps adding an Application Proxy](/other/troubleshooting/cisco-ise-host-header-limitation) to work with SCEPman. ## Microsoft Network Policy Server (NPS) NPS maps certificates to device or user entities in AD (not AAD). As there is no device synchronization out-of-the-box between AAD and AD, it is usually not possible to use NPS with device certificates distributed via Intune with SCEPman or any other PKI. User certificates can work for users synchronized between AAD and AD. The certificates must contain the users' UPNs, which NPS uses to map to AD user objects with the same UPN. ## Others Generally, you have to add the SCEPman Root CA certificate as a trusted CA in the NAC. Possibly, you have to manually add the SCEPman OCSP URL. You can find the OCSP URL in the Authority Information Access (AIA) extension of any client certificate. # Certificate-based Authentication for Entra ID Certificate-based authentication offers a strong security alternative for accessing Entra ID resources. This article provides a walkthrough of how to configure this method, utilizing SCEPman as the Certificate Authority to streamline certificate management. ## Enable SCEPman CRL {% content-ref url="/pages/e8BwMM8UxsW2rCH3NnWd" %} [Enabling CRL](/certificate-management/manage-certificates/enabling-crl) {% endcontent-ref %} Entra ID will require a CRL to validate the certificates. Make sure to set the following environment variables in your app service for the CRL to be available: [AppConfig:CRL:RequestToken](https://docs.scepman.com/scepman-configuration/application-settings/crl#appconfig-crl-requesttoken) Set this to a custom string that will be used in the URL to allow the CRL to be downloaded. [AppConfig:CRL:Source](https://docs.scepman.com/scepman-configuration/application-settings/crl#appconfig-crl-source) This is the source that SCEPman builds the CRL from. Make sure that this is set to `Storage` ## Setup Entra ID {% stepper %} {% step %} ### Create PKI in Entra Security Center In Entra ID, navigate to **Protection** > **Security Center** > [**Public Key Infrastructure**](https://entra.microsoft.com/#view/Microsoft_AAD_IAM/SecurityMenuBlade/~/PublicKeyInfrastructure/menuId/SecurityCenter/fromNav/)**,** click on *Create PKI* and select a matching display name. {% endstep %} {% step %} ### Add Certificate Authority Navigate to the newly created PKI and click on *Add certificate authority* to upload the CA certificate of your SCEPman instance. This certificate can be obtained from its homepage in the menu on the right side (*Get CA Certificate*). For the Certificate revocation list URL you can enter the URL in the following format: ``` https://scepman.contoso.com/crl/pem/{YourCrlRequestToken} ``` {% hint style="warning" %} Make sure to include the `/pem/` path in your URL as Entra might have compatibility issues when using the default DER format. {% endhint %} This should now leave you with a certificate authority similar to the following:
{% endstep %} {% step %} ### Enable CBA in Authentication Methods With the CA in place, we can go on and enable certificate based authentication in **Protection** > **Authentication methods** > [**Policies**](https://entra.microsoft.com/#view/Microsoft_AAD_IAM/AuthenticationMethodsMenuBlade/~/AdminAuthMethods/fromNav/) Go to the *Certificate-based authentication* policy, enable it and allow either all users or specific groups to use this method: ![](/files/6iGzcg56a15mZtxIEmq4) {% endstep %} {% step %} ### Configure Certificate-based Authentication Switch to the *Configure* tab and go through the options: **Require CRL validation**: ✅ This is an essential part of the security this method provides as the CRL will tell Entra ID which certificates have been revoked and shall therefore not be allowed for authentication. **Issuer Hints** : ✅ Enabling the issuer hints will only show certificates during authentication, that are issued by the configured CA. Leave the default settings for authentication binding and go on to create a rule to allow the earlier created certificate authority:
**Authentication strength**: This defines the weight of the authentication using this CA. If you select *Single-factor authentication*, another authentication method can be necessary depending on the application to be accessed. **Affinity binding**: The affinity binding defines the required details in the certificate, that needs to match correlating data in the user object, for the authentication to be allowed. As SCEPman can currently not add any certificate information in user object we recommend to set this to **Low** unless you configure the required information manually. {% hint style="warning" %} The authentication strength and affinity binding settings highly depend on the specific use case and the kind of accounts you want to protect with this authentication method. In case you want to secure highly privileged users you should think of manually adding the certificate information in their user accounts for a high affinity. {% endhint %} {% endstep %} {% endstepper %} ## Usage With the configuration being in place, a user can select *Use a certificate or smart card*:
Which will in turn ask for the certificate to be used for authentication.
## Manually adding certificate mapping for high affinity binding In case you want to enable CBA only using high affinity binding you can manually enter the certificates details in the authorized information of the user. Navigate to the users properties in Entra ID, edit them and now edit the **Certificate user IDs**:
The required format of these IDs depends on the fields that have been configured in the authentication methods user binding. A list of formats can be found in the corresponding [Microsoft documentation](https://learn.microsoft.com/en-us/entra/identity/authentication/concept-certificate-based-authentication-certificateuserids#supported-patterns-for-certificate-user-ids). Example for the *SHA1PublicKey* binding: ``` X509:9600e49d740011187e5c734bab4a3d5d18d2a87a ``` This is using the certificates thumbprint to strongly map the identity of the user. # Certificate-based Authentication for RDP You can use SCEPman to issue Smart Card Login certificates to your users. By enrolling them to Windows Hello for Business (*Microsoft Passport Key Storage Provider*) they can use these certificates to authenticate to on premises resources using their Hello PIN or biometric options. This will allow users for example to connect to other clients over the Remote Desktop Protocol (RDP) using their Windows Hello for Business credentials. ## Setup Active Directory ### Requirements * SCEPman's CA certificate must be published in the **NTAuth** store to authenticate users to Active Directory * Domain Controllers need to have a domain controller certificate to authenticate smartcard users * Domain Controllers and target machines need to trust SCEPmans Root CA Follow our guide on Domain Controller certificates to publish the SCEPman Root CA certificate to the **NTAuth** store and issue certificates to your domain controllers: {% content-ref url="/pages/-MGc2XaFPxVjrhBXwHXS" %} [Domain Controller Certificates](/certificate-management/domain-controller-certificates) {% endcontent-ref %} You can create a **Group Policy Object** to handle the distribution of the root certificate to the involved machines:[ To distribute certificates to client computers by using Group Policy](https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/deployment/distribute-certificates-to-client-computers-by-using-group-policy#to-distribute-certificates-to-client-computers-by-using-group-policy) The certificate needs to be deployed to all Domain Controllers handling the authentications and all target machines that users want to connect to using this method. {% hint style="danger" %} Please be aware that once SCEPmans root certificate is published in the NTAuth store, users who can influence the content of certificates issued by SCEPman (e.g. Intune administrators) are able to impersonate any Active Directory principal. {% endhint %} ## Deploy the Smart Card Certificates using Intune ### Trusted Certificate Profile Your clients will need to [trust the root certificate of SCEPman](https://docs.scepman.com/certificate-deployment/microsoft-intune/windows-10#root-certificate). If you already use SCEPman to deploy certificates to your clients you will already have this profile in place. ### Smart Card Certificate Create a profile for **Windows 10 and later** with type **SCEP certificate** in Microsoft Intune and configure the profile as described:
Certificate type: User
Subject name format: CN={{UserPrincipalName}} If the targeted users UPN suffix in Entra ID happens to be different to the one used in Active Directory you should use `CN={{OnPrem_Distinguished_Name}}`
Subject alternative name: UPN value: {{UserPrincipalName}} and URI value: {{OnPremisesSecurityIdentifier}} The URI with the SID is necessary to have a [Strong Certificate Mapping](/scepman-configuration/application-settings/certificates#appconfig-addsidextension) in AD. Alternatively, you can configure SCEPman to [add a extension with the SID](/scepman-configuration/application-settings/scep-endpoints/intune-validation#appconfig-intunevalidation-waitforsuccessnotificationresponse) to user certificates and not configure the URI.
Key storage provider (KSP): Enroll to Windows Hello for Business, otherwise fail (Windows 10 and later)
Key usage: Digital signature and Key encipherment
Key size (bits): 2048
Hash algorithm: SHA-2
Root Certificate: Profile from previous step (Trusted Certificate Profile)
Extended key use: Client Authentication and Smart Card Login `Client Authentication, 1.3.6.1.5.5.7.3.2` `Smart Card Logon, 1.3.6.1.4.1.311.20.2.2`
SCEP Server URLs: Open the SCEPman portal and copy the URL of Intune MDM
### Use Windows Hello for Business to connect to remote hosts With the certificate deployed to the authenticating client, just connect to the remote host and select the configured Windows Hello for Business credential provider.
# Permissions {% content-ref url="/pages/-MCkO9Avuz4fiIfipZsZ" %} [Azure App Registration](/scepman-deployment/permissions/azure-app-registration) {% endcontent-ref %} {% content-ref url="/pages/8WU2d52tz1E751TB5wn2" %} [Managed Identities](/scepman-deployment/permissions/post-installation-config) {% endcontent-ref %} # Azure App Registration {% hint style="info" %} Only relevant for [Split-Tenancy](/azure-configuration/split-tenancy) setups. {% endhint %} SCEPman needs to interact with your Azure Active Directory and Intune endpoints to provide the certificate and OCSP validation of users and devices. To provide the necessary permissions to SCEPman you need to create an App Registration within your tenant. ## Generate App Registration (get Application ID) 1. Login to [Azure Portal](https://portal.azure.com) 2. Navigate to **Azure Active Directory** 3. Click **App registrations** ![](/files/-MfH6y_XFUm45AwIZEyy) 4\. Click **New Registration** and enter a **name**, i.e. SCEPman. For supported account type choose **Accounts in this organizational directory only** and click register. ![](/files/-MfH7Ed37h2L137C6VLU) 5\. You may copy the **Application (client) ID** now. The ID is important and will be needed later by SCEPman deployment. ![](/files/-MfH7XZycUEjhAcSj35b) Create a new environment variable in SCEPman app service with the name [AppConfig:AuthConfig:ApplicationId](/scepman-configuration/application-settings/dependencies-azure-services/azure-ad#appconfig-authconfig-applicationid) and paste the copied application ID as a value. ## Generate Secret (get Client Secret Value) 1\. Stay within **App registrations** and click on **Certificates & secrets** ![](/files/-MfH7o-eH7gfqR5pN6_c) 2\. Click **New client secret**, add a description, and choose the expiration. We recommend **24 months**, this helps to provide an ongoing service for two years. You can revoke a secret at any time. Click **Add** ![](/files/-MfHBtimIqsGBl90NUIa) 3\. **Copy the secret value** and copy it down in a secure place. {% hint style="warning" %} Please do not mix it up with the "Client Secret **ID**". We need the "Client Secret **Value**", here. {% endhint %} {% hint style="warning" %} Copy the client secret value immediately. You will not be able to retrieve it after you leave this submenu. {% endhint %} ![](/files/bPw2k8DDcgtki8yLBCA9) 4. Create the SCEPman setting [AppConfig:AuthConfig:ApplicationKey](/scepman-configuration/application-settings/dependencies-azure-services/azure-ad#appconfig-authconfig-applicationkey) with the client secret value. ## Configure Permissions Stay within **App Registrations** and click on **API permissions** 1. **Remove** the default **User** **Read** permission. ![](/files/-M-9TVCAmrCJoJxQ-aJu) 2\. Click on **Add a permission** and choose **Microsoft Graph**. When chosen, select **Application permissions** and search for directory. Add **Directory.ReadAll** as permission. ![](/files/-MCkOEGZjGfZzetmMBlQ) ![](/files/-M-9UK8Cb-CtV_lQchYj) 3\. Now click on **Add a permission** and choose **Intune**. When chosen, select **Application permissions** and search for scep. Add **scep\_challenge\_provider** as a permission ![](/files/-M-9UvMNcGjQpTrjZCNi) ![](/files/-M-9UyM5IEFKZ9Tabzvp) 4. Search and add the following Graph permissions as well: `DeviceManagementConfiguration.Read.All` and `DeviceManagementManagedDevices.Read.All` 5. Finally click on **Grant admin** consent and **confirm** the consent for the given app registration.
6. After successfully granting the permissions you should see green status for each permission.
The app registration is done. # Managed Identities {% hint style="info" %} This feature requires version **2.0** or above. {% endhint %} SCEPman needs to interact with your Entra Directory and Intune endpoints to provide the certificate and OCSP validation of users and devices. After deployment, SCEPman does not yet have the required permissions to access these services. The PowerShell Module described in this article adds the necessary permissions to the SCEPman App Service's Managed Identity and completes the installation. Additionally, the PowerShell Module adds the required background wiring for the SCEPman Certificate Master component introduced with SCEPman 2.0. In case you upgraded from SCEPman 1.x to SCEPman 2.x, the PowerShell Module even adds two new Azure Resources for the SCEPman Certificate Master component. ## Acquire and run the SCEPman Installation PowerShell Module Whether you have just installed a fresh SCEPman 2.x installation or if you have just upgraded from SCEPman 1.x to SCEPman 2.x, and in some cases after deployment architecture changes, the installation steps are the same. You download and run the SCEPman PowerShell Module, which detects what needs to be done and completes the installation. You can run the SCEPman Module as often as you want, it will only add what is yet missing. ### Prerequisites * A **Global Admin** Account for the tenant to which you want to install SCEPman (or another AAD role like *Privileged Role Administrator* and write permissions to the Azure Subscription). There is an option to use an account with only the *Application Administrator* role and execute the commands requiring Global Administrator permissions later manually. * [Azure CLI](https://docs.microsoft.com/en-us/cli/azure/install-azure-cli) (also known as *az*) installed. Azure CLI is pre-installed in the [Azure Cloud Shell](https://docs.microsoft.com/en-us/azure/cloud-shell/overview), the preferred way to run the module. ### Running the SCEPman Installation CMDlet #### Enabled Homepage Once the prerequisites are met, you can install the SCEPman installation module from PowerShell Gallery and then run the CMDlet to complete the SCEPman and Certificate Master installation. 1. First, you need to navigate to the SCEPman App Service and click on Default domain (see screenshot below). This will navigate you to the SCEPman homepage.
2. Run the PowerShell command displayed on the homepage of your SCEPman instance in your PowerShell or Azure Cloud Shell (see screenshot below). This includes a parameter to identify your SCEPman instance, so the code can run ideally without any user interaction. ![](/files/atNs1TaMMixZut8XWuhU) {% hint style="warning" %} After running the CMDlet, you may get "Service not available" or "502 Server Error" on SCEPman homepage, please wait 2-3 minutes and refresh the page again. {% endhint %} #### Disabled Homepage If you have disabled the SCEPman Homepage or need to execute the CMDlet again, do the following: 1. Paste the below code in your PowerShell or Azure Cloud Shell: ``` Install-Module SCEPman -Scope CurrentUser -Force Complete-SCEPmanInstallation 6>&1 ``` 2. Fill in the prompts for: * Which Azure Subscription SCEPman runs in (if there is more than one you have access to) * The name of the SCEPman App Service (not required if you used the code from the SCEPman Homepage) 3. (For SCEPman upgrades only), you need two extra confirmations: * The name of the new SCEPman Certificate Master App Service (you can confirm the suggestion by hitting enter or typing a new name for the resource) * The name of the new Storage Account resource (again, you can confirm the suggestion by hitting enter or typing a new name for the resource) ### Running the SCEPman Installation CMDlet without Global Admin Role Use the *-SkipAppRoleAssignments* flag of Complete-SCEPmanInstallation to run the CMDlet without Global Admin permissions. This will skip the assignment of the required App Roles to the SCEPman and Certificate MasterApp Services' Managed Identities. You can then assign the App Roles manually as a Global Administrator. The CMDlet will print the required commands to the console. ### Considerations when using Deployment Slots The SCEPman module updates the configuration in all deployment slots unless you tell it to use just one specific deployment slot with the parameter `-DeploymentSlotName` (which cannot be the main one, because technically it is no deployment slot). The configuration update changes the SCEPman settings to **use** **Managed Identity authentication instead of Enterprise App authentication**. SCEPman 1.x **does not** support Managed Identity authentication and therefore the CMDlet renders deployment slots unusable that still run a 1.x version. Thus, if you have multiple deployment slots and do not want to upgrade all of them at once, you should update the production slot last -- **its upgrade also affects all other deployment slots**. For other deployment slots, use the `-DeploymentSlotName` parameter to target only these individual deployment slots. This is what the PowerShell commands displayed on the deployment slot's SCEPman homepage display, so you can just copy the commands. Once all your deployment slots are running on 2.x, just execute the Complete-SCEPmanInstallation CMDlet once more and then all of them use Managed Identities. {% hint style="danger" %} If you accidentally updated a deployment slot to Managed Identity authentication that still runs SCEPman 1.x, please look at the [downgrade guide](https://docs.scepman.com/scepman-deployment/permissions/pages/-MCkO9AyXaqifRD7KuiV#downgrade-from-2.x-to-1.x) to make it work again. {% endhint %} ### Considerations when Installing SCEPman Multiple Times in One Tenant The CMDlet Complete-SCEPmanInstallation creates two App Registrations: `SCEPman-api` and `SCEPman-CertMaster`. [Section "How the CMDlet Configures SCEPman Certificate Master](#how-the-cmdlet-configures-scepman-certificate-master)" explains what these App Registrations do. The CMDlet requires that their names are unique, so if you have multiple SCEPman installations in one tenant, they will share these App Registrations by default. This means that users have the same roles on all Certificate Masters and that, technically, each Certificate Master instance can submit certificate requests to any SCEPman (although that does not happen unless you configure SCEPman Certificate Master to do that). If you don't want that behavior, for example, because the SCEPman installations belong to different parts of your organization, or one SCEPman installation is a pre-production environment, or you want a multi-tier PKI with a SCEPman Root CA and a SCEPman Issuing CA, you need to tell the SCEPman instances to use other app registrations. For this purpose, the Complete-SCEPmanInstallation CMDlet features the two parameters `-AzureADAppNameForSCEPman` and `-AzureADAppNameForCertMaster`. These parameters let you define different names for your App Registrations. For example, you might call the CMDlet like this for your Root CA:\ `Complete-SCEPmanInstallation -SCEPmanAppServiceName app-scepmanroot -SearchAllSubscriptions -AzureAdAppNameForSCEPman SCEPman-api-root -AzureAdAppNameForCertMaster -SCEPman-CertMaster-root 6>&1` And then you call it another time for your Subordinate CA like this: `Complete-SCEPmanInstallation -SCEPmanAppServiceName app-scepmansub -SearchAllSubscriptions -AzureAdAppNameForSCEPman SCEPman-api-sub -AzureAdAppNameForCertMaster -SCEPman-CertMaster-sub 6>&1` ## Background Details of the SCEPman PowerShell Module This section describes the inner workings of the PowerShell Module. This may help if you have a special configuration that requires altering the script, if you need to grant some special permission, if you are troubleshooting issues with a SCEPman installation, or if you want to understand the inner workings to write an installation script for your own project. Note that the PowerShell Module is Open Source Software. You can review the source code in its [GitHub Repository](https://github.com/scepman/scepman-psmodule). Pull Requests are welcome! We recommend to execute the commandlet with `6>&1`, which redirects the information stream and prints it on the screen, which gives more information about the state of the program than if you leave out the redirection. If you add `-Verbose`, there will be even more information about what the script does. ### How the CMDlet Configures SCEPman The PowerShell CMDlet searches for the SCEPman App Service. The App Service uses a system-assigned Managed Identity, which already has access rights to the SCEPman's Azure Key Vault in a regular installation. The CMDlet adds permissions to access Microsoft Graph to search for users and devices in AAD and Intune for incoming OCSP requests and to Intune itself to verify incoming SCEP requests. ### How the CMDlet Handles Updates from SCEPman 1.x In addition to granting the rights to SCEPman, the Module adds two new Azure Resources when performing an upgrade: * The SCEPman Certificate Master App Service * The Storage Account shared by SCEPman and SCEPman Certificate Master for manually created certificates Even for the Community Edition, which does not use the SCEPman Certificate Master component, the two new resources are added. This enables switching to the Enterprise Edition more easily if you want, and does not add any extra cost -- the Storage Account will be empty and Microsoft bills this by the amount of storage, and the Certificate Master App Service shares an App Service Plan with SCEPman, which also adds no extra cost. SCEPman 1.x used an App Registration to authenticate against Microsoft Graph and Intune, while SCEPman 2.x can use its Managed Identity. The CMDlet switches to the Managed Identity by changing these settings: * [AppConfig:AuthConfig:ApplicationId](/scepman-configuration/application-settings/dependencies-azure-services/azure-ad#appconfigauthconfigapplicationid) is set to a newly created app registration without any permissions. It is used to authenticate *against* SCEPman, not for SCEPman authenticating somewhere else. The old value is backed up as `Backup:AppConfig:AuthConfig:ApplicationId`. * [AppConfig:AuthConfig:ApplicationKey](/scepman-configuration/application-settings/dependencies-azure-services/azure-ad#appconfigauthconfigapplicationkey) is deleted, the old value is backed up as `Backup:AppConfig:AuthConfig:ApplicationKey`. It is not needed anymore, because SCEPman does not authenticate as the Application. * [AppConfig:AuthConfig:ManagedIdentityEnabledOnUnixTime](/scepman-configuration/application-settings/dependencies-azure-services/azure-ad#appconfigauthconfigmanagedidentityenabledonunixtime) contains the time when the CMDlet was run. SCEPman acquires a token using the Managed Identity only after a short delay after the CMDlet was run, because only then do the roles in the token reflect the correct permissions added by the CMDlet. ### How the CMDlet Configures SCEPman Certificate Master The SCEPman App Service allows anonymous access to its homepage, as it only displays non-sensitive read-only information. In contrast, the SCEPman Certificate Master component allows users to issue certificates. Hence, it allows only authenticated access and only if you have the right permissions. This requires an Azure App Registration with Delegated Permissions to see who is logged in and with the right log-in URL configuration. The module registers this App Registration as `SCEPman-CertMaster` in your Azure tenant. Additionally, the SCEPman Certificate Master App Service needs permission to submit Certificate Signing Requests (CSRs) to the core SCEPman App Service to issue certificates. The authentication mechanism behind this founds on another App Registration: `SCEPman-api`. SCEPman uses *SCEPman-api* to manage CSR submission permissions. The script registers SCEPman-api and adds the submission permission to the SCEPman Certificate Master Managed Identity. {% hint style="info" %} In case of upgrading SCEPman from 1.x to 2.x and after successfully running the PS script, you can remove the App Registration that was used in SCEPman 1.x SCEPman V2.x uses two new App Registrations: "SCEPman-api" and "SCEPman-CertMaster" {% endhint %} # Deployment Options We offer three different deployment options: The [**Marketplace deployment**](/scepman-deployment/deployment-options/marketplace-deployment) is valid for community and enterprise deployments. For advanced configuration for SCEPman Enterprise edition (SCEPman EE), you can choose the [**Enterprise deployment**](/scepman-deployment/deployment-options/enterprise-deployment). If you are using Terraform to deploy your Azure resources, you can use the [**Terraform deployment**](/scepman-deployment/deployment-options/terraform-deployment). {% content-ref url="/pages/-MCkO9Ax5vQDsk6iokZq" %} [Marketplace deployment](/scepman-deployment/deployment-options/marketplace-deployment) {% endcontent-ref %} {% content-ref url="/pages/-MCkO9AyXaqifRD7KuiV" %} [Enterprise deployment](/scepman-deployment/deployment-options/enterprise-deployment) {% endcontent-ref %} {% content-ref url="/pages/2Rs4K4ETWZIl5EnDDTDW" %} [Terraform deployment](/scepman-deployment/deployment-options/terraform-deployment) {% endcontent-ref %} # Marketplace deployment Azure Marketplace Deployment * To deploy SCEPman from Azure Marketplace, please visit this [**link**](https://azuremarketplace.microsoft.com/en-us/marketplace/apps/glueckkanja-gabag.scepman?tab=Overview). * Click **Get it now** and afterwards **Continue**. You will be re-directed to the marketplace item on Azure Portal.
* Click **Create**. * Now, follow these steps to deploy SCEPman in your Azure tenant:
{% hint style="info" %} If you have a license key, you can paste it into the field **License Key**. Leave it empty to use the free Community Edition of SCEPman. {% endhint %} {% hint style="warning" %} To maximize compatibility, for the **Organization Name** we recommend to omit * language-specific special characters (e.g. ö, ø, é, ...) * a leading space (spaces between words can be used) * quotation marks {% endhint %} 1. Select an existing **resource group** or create a new one (SCEPman resources will be deployed in this group) 2. Set the **region** according to your preferred data center location. It **must** match the region of the resource group - in case you have selected an existing one. It will be assigned to the resource group otherwise. 3. Set an **Organization Name**. This field is **important** as the organization provided here will manifest itself in the O= field of the Root CA that is going to be created later on. 4. Select your preferred **Update Channel**. By default, the [Evergreen approach](/azure-configuration/update-strategy#evergreen-approach) is configured as [update strategy](/azure-configuration/update-strategy). This parameter determines from which [channel](/scepman-configuration/application-artifacts) the binaries for SCEPman will be loaded. For production environments, we recommend to use the **Production Channel** (default). 5. Click **Review + Create**. 6. Click **Create**. Congratulations! The deployment of SCEPman is done. Please continue with the [next step](/scepman-deployment/deployment-guides/community-guide#step-2-perform-post-deployment-steps-permission-assignments) of the [Standard Guide](/scepman-deployment/deployment-guides/community-guide) to complete the installation of SCEPman. # Enterprise deployment GitHub Deployment ## New SCEPman Instance **Deploy Azure Resources** Log in with an AAD administrator account and visit this site, choose and click one of the following deployment links: * [Production channel](https://portal.azure.com/#create/Microsoft.Template/uri/https%3A%2F%2Fraw.githubusercontent.com%2Fscepman%2Fdeploy%2Fprod%2Fazuredeploy.json) * [Beta channel](https://portal.azure.com/#create/Microsoft.Template/uri/https%3A%2F%2Fraw.githubusercontent.com%2Fscepman%2Fdeploy%2Fbeta%2Fazuredeploy.json) * [Internal channel](https://portal.azure.com/#create/Microsoft.Template/uri/https%3A%2F%2Fraw.githubusercontent.com%2Fscepman%2Fdeploy%2Finternal%2Fazuredeploy.json) * [Production channel in GCC High national cloud](https://portal.azure.us/#create/Microsoft.Template/uri/https%3A%2F%2Fraw.githubusercontent.com%2Fscepman%2Fdeploy%2Fgcchigh%2Fazuredeploy.json) * [Production channel in 21Vianet national cloud](https://portal.azure.com/#create/Microsoft.Template/uri/https%3A%2F%2Fraw.githubusercontent.com%2Fscepman%2Fdeploy%2Fvianet%2Fazuredeploy.json) (Experimental!) Fill out the values in the form
* **Subscription:** Select your subscription, where you have permissions to create app services, storage account, app service plan, and key vault * **Resource group:** Select an existing resource group or create a new one. The SCEPman resources will be deployed to this resource group * **Region:** Select the region according to your location * **Org Name:** Name of your company or organization for the CA certificate subject name (O RDN) {% hint style="warning" %} To maximize compatibility, for the **Org Name** we recommend omitting * language-specific special characters (e.g. ö, ø, é, ...) * a leading space (spaces between words can be used) * quotation marks {% endhint %} * **License:** leave as "trial" to deploy a Community Edition or paste your license key for the Enterprise Edition of SCEPman. * **Ca Key Type**: * **RSA-HSM** (**recommended**, HSM-backed root CA) * **RSA** (software-backed root CA) * For the **Storage Account Name**, please notice that the name **must** be between 3 and 24 characters in length and may contain **numbers and lowercase letters only** * Define a **globally** unique name for the **Key Vault Name, App Service Plan Name,** **Primary App Service Name**, **Log Analytics Workspace Name**, **Certificate Master App Service Name**, **Virtual Network Name**, **Private Endpoint for Key Vault Name** and **Private Endpoint for Table Storage.** Replace *UNIQUENAME* with a value that hints at your organization name. {% hint style="warning" %} In case you have previously deployed SCEPman with the same **Key Vault Name**, and deleted all resources of the previous deployment, make sure to [**recover**](https://learn.microsoft.com/en-gb/azure/key-vault/general/key-vault-recovery?tabs=azure-portal\&WT.mc_id=Portal-Microsoft_Azure_KeyVault#list-recover-or-purge-a-soft-deleted-key-vault) the previously deleted Key Vault. It will re-appear in the previous resource group. The ARM deployment - if pointed to the same resource group - will recognize the existing Key Vault and re-use it. A full deletion of the previous Key Vault is not feasible due to [**Purge Protection**](https://learn.microsoft.com/en-gb/azure/key-vault/general/key-vault-recovery?tabs=azure-portal\&WT.mc_id=Portal-Microsoft_Azure_KeyVault#what-are-soft-delete-and-purge-protection) for 90 days. {% endhint %} * **Existing App Service Plan ID:** Provide the App Service Plan ID of an existing App Service Plan or keep the default value 'none' if you want to create a new one To find your **existing App Service Plan ID:** navigate to your existing App Service Plan > JSON View > copy the Resource ID (see screenshots) ![](/files/nP3yNaF4waUxUOntbySi) ![](/files/mQpow2ODWuFQpityZPaP) * **Deploy on Linux:** * **true** (deploys SCEPman on a Linux App Service Plan) * **false** (deploys to a Windows App Service Plan) * **Deploy Private Network**: * **true** (**recommended**, isolates the key vault and storage account behind private endpoints so that only SCEPman can access them from a networking perspective) * **false** (key vault and storage account can be accessed from any IP address) * **Location:** of all resources, the default value `[resourceGroup().location]` is Microsoft recommendation, you can just leave it as it is * **Review + create**, then **Create** After a successful deployment of SCEPman please follow the[ Managed Identities ](/scepman-deployment/permissions/post-installation-config)article # Terraform deployment Terraform Deployment If you are using Terraform to deploy your Azure resources, you can use our Terraform module to deploy SCEPman in your Azure tenant. You can find usage instructions and examples on the [module page in the Terraform Registry](https://registry.terraform.io/modules/scepman/scepman/azurerm/latest). # Root CA After you have deployed your SCEPman environment you have to create a root certificate. If you want to use an intermediate certificate (Enterprise Edition only) you can have a look at this guide: {% content-ref url="/pages/zw1h98V8KpyCiUSAcwpJ" %} [Intermediate CA](/scepman-deployment/intermediate-certificate) {% endcontent-ref %} **For a standard SCEPman setup, we recommend generating a new root certificate with the following steps:** ## Create SCEPman Root certificate 1. Navigate to **App Services**. 2. Choose the SCEPman application and click on **Browse** to see the SCEPman website. 3. When everything works as intended **Intune**, **Read AAD, Read Intune,** and **Storage Account** are set in green as **connected**. ![](/files/qRecvKD9aFLGS32lk3tO) 4\. The option **click here to start** creating the Azure Key Vault RootCA certificate. The initial root certificate should be created only once on a farm.\ 5\. Select **I have read the documentation\[...]** and click **Create First Node**.\ 6\. After some seconds/minutes you can refresh the page. Now you should see that the root certificate is available.
Now you are ready to start! Check [Certificate Deployment via Microsoft Intune](/certificate-management/microsoft-intune) # Intermediate CA {% hint style="warning" %} SCEPman Enterprise Edition only {% endhint %} 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. ## Key Vault Permissions 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: {% tabs %} {% tab title="Azure RBAC" %} 1. Navigate to your Azure Key Vault in the Azure Portal 2. Click on **Access control (IAM)** in the left navigation pane. 3. Click on **Role assignments** and add a new role assignment

Add a new role assignment to your Key Vault

4. Select the **Key Vault Certificate Officer** role and click **Next**
5. 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. {% endtab %} {% tab title="Vault Access Policies" %} 1. Navigate to your Azure Key Vault in the Azure Portal 2. Click on **Access policies** in the left navigation pane. 3. Click on **Create** and choose the **Certificate Management** template, then next
4. Now search and add your AAD admin account in the **Principal** section, then next, next, and create
After adding the permissions, your Azure AD account is permitted to create a CSR and upload the certificate. {% endtab %} {% endtabs %} ## Open Key Vault Networking to the Admin System If you are using a [Private Endpoint](/azure-configuration/private-endpoints) 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. * 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". * Add the IP address of the client on which you want to [run the SCEPman PowerShell module later on](#creating-intermediate-ca-certificate-with-the-scepman-powershell-module). If you are using the Azure Cloud Shell and [it is connected to a VNET](https://learn.microsoft.com/en-us/azure/cloud-shell/vnet/overview), 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. ## Update Azure App Service Settings 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. 1. Navigate to your Azure App Service 2. Click on **Environment variables** in the left navigation pane 3. In **Application settings,** you must edit the following settings: 1. `AppConfig:KeyVaultConfig:RootCertificateConfig:CertificateName`\ Change this to a preferred common name (CN) for your intermediate CA. 2. `AppConfig:KeyVaultConfig:RootCertificateConfig:Subject`\ Only change the CN value of the subject name to match the common name used above. 4. Click on **Apply and Confirm.** 5. Restart the Azure **App Service** to apply the changes then navigate to your SCEPman URL. {% hint style="warning" %} 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 {% endhint %}
## Creating Intermediate CA Certificate with the SCEPman PowerShell Module {% hint style="warning" %} To ensure this module functions correctly, you will need a workstation with [Azure CLI](https://docs.microsoft.com/en-us/cli/azure/install-azure-cli) (also known as `az`) installed. The Azure CLI is pre-installed in the [Azure Cloud Shell](https://docs.microsoft.com/en-us/azure/cloud-shell/overview), which is the recommended environment for running this module. {% endhint %} 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: ```powershell Install-Module -Name SCEPman -Scope CurrentUser -Force ``` Then, you can tell the module the name of your organization to appear in the certificate: ```powershell Reset-IntermediateCaPolicy -Organization "My Organization" ``` 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): {% code lineNumbers="true" %} ``` $policy = Get-IntermediateCaPolicy $policy.policy.x509_props.subject = "CN=YOUR_CN_FROM_ABOVE,OU=YOUR_TENANT_ID,O=YOUR_ORGANIZATION" # change some additional settings of $policy Set-IntermediateCaPolicy -Policy $policy ``` {% endcode %} Finally, you can create the CSR with the following command (or a similar one according to your environment): ```powershell New-IntermediateCA -SCEPmanAppServiceName "app-scepman-example" -SearchAllSubscriptions 6>&1 ``` The command will output the CSR that you submit to your Root CA for signing. ## Issue the Intermediate CA Certificate 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. ### Special Steps for an ADCS Enterprise Root CA 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. #### Outline 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`. #### Step by step 1. Request and issue a SubCA certificate. 2. 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. 3. Create a file "extfile.txt" with the contents shown below to the Root CA (e.g. c:\temp\extfile.txt). 4. Start command line and execute: `certutil -sign "c:\temp\SubCA.cer" "c:\temp\SubCAwithKeyEncipher.cer" @c:\temp\extfile.txt` 5. The certificate SubCAwithKeyEncipher.cer now contains the requested key usage (0xA6). The thumbprint (signature) has changed, but the serial number hasn't. 6. 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`. #### extfile.txt ``` [Extensions] 2.5.29.15=AwIBpg== Critical=2.5.29.15 ``` ## Upload the Intermediate CA Certificate 1. In Azure Key Vault, click on your certificate and press **Certificate Operation** 2. Now you can see the options **Download CSR** and **Merge Signed Request** ![](/files/-MeOvPyZCahlrZ2Pt3VU) 1. 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** {% hint style="warning" %} 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. {% endhint %} ## Verify CA Suitability On the SCEPman Status page, you can see the new configuration and download the new intermediate CA certificate to deploy this via Endpoint Manager. 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 [Issue the Intermediate CA Certificate](#issue-the-intermediate-ca-certificate) and correct the certificate issuance. ## Intermediate CAs and Intune SCEP Profiles 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. # Revocation Automatic certificate revocation in Microsoft Intune or Jamf Pro via OCSP using SCEPman. SCEPman offers several ways to manage and revoke a certificate. The available options depend on * whether the certificate was automatically enrolled via an MDM solution or whether it was generated via the [Certificate Master UI](/certificate-management/certificate-master) / [Enrollment REST API](/certificate-management/api-certificates), * the MDM system that is used for (automatic) enrollment, and * the configuration of SCEPman. Below section provides an overview of the different management options and revocation mechanisms and under which circumstances they are available. ## Automatic Revocation {% hint style="info" %} Only available when **Microsoft Intune** and/or **Jamf Pro** are used as MDM solution(s) for certificate enrollment. Alternatively, it is available with any 3rd party MDM that is able to sync device and/or user objects with Microsoft Entra ID (Azure AD) (i.e. [Static AAD Validation](/scepman-configuration/application-settings/scep-endpoints/staticaad-validation) can be used). {% endhint %} {% hint style="success" %} Supported on **OCSP**. {% endhint %} ### Background Automatic revocation is **always active** and enables convenient certificate lifecycle management by linking each certificate to a directory object such as a user or device identity. Through this object binding mechanism, SCEPman can infer the revocation status based on certain lifecycle characteristics of the object is has been linked to. The mapping from the object's lifecycle state to the certificate's revocation state is implemented to match best practices from years of security and endpoint management experience. The binding between directory object (user or device) and certificate is established by introducing appropriate variables in the SCEP profile for the Subject Name or Subject Alternative Name properties. Upon receiving a Certificate Signing Request (CSR) from an MDM-managed client, SCEPman identifies the bound object and encodes this information into the serial number of the certificate before returning it to the client. It is the serial number that is transmitted to SCEPman's OCSP responder during certificate validation, allowing SCEPman to decode the object information, perform a search of the appropriate directory, and finally make a revocation status decision. ### Revocation Behavior {% hint style="success" %} In any of the below scenarios, revocation can be considered to be effective immediately, once the bound object's state has changed. Please note that local caching of OCSP responses on the client may suggest otherwise. {% endhint %} {% hint style="warning" %} During testing, please consider that deleting/removing a device from the respective directory/MDM solution is an irreversible operation that will require you to re-enroll the device afterwards. {% endhint %}
Bound ObjectDelete from DirectoryDisable in DirectoryOptional
Intune Device {{DeviceId}}Delete, Wipe*, Retire*: permanent revocationNot available
Entra (Azure AD) Device
{{AAD_Device_ID}}
Delete: permanent revocationDisable: reversible revocation
Entra (Azure AD) User
{{UserPrincipalName}}		Delete: permanent revocationDisable: reversible revocation
Jamf Computer
CN=$JSSID,OU=computers		Delete: permanent revocationNot availableNot available
Jamf Device
CN=$JSSID,OU=devices		Delete: permanent revocationNot availableNot available
Jamf User on Computer
CN=$JSSID,OU=users-on-computers
  • Delete (Computer): permanent revocation
  • Delete (User): permanent revocation
Not availableNot available
Jamf User on Device
CN=$JSSID,OU=users-on-devices
  • Delete (Device): permanent revocation
  • Delete (User): permanent revocation
Not availableNot available
\*: Ensure during wipe, that "Wipe device, but keep enrollment state and associated user account" is **disabled**. Revocation is only immediate if [AppConfig:IntuneValidation:RevokeCertificatesOnWipe](/scepman-configuration/application-settings/scep-endpoints/intune-validation#appconfig-intunevalidation-revokecertificatesonwipe) is set to true (default). ## Manual Revocation {% hint style="warning" %} SCEPman Enterprise Edition only {% endhint %} {% hint style="info" %} This feature requires version **2.3** or above. {% endhint %} {% hint style="success" %} Supported on **OCSP** and [**CRL**](/scepman-configuration/application-settings/crl). {% endhint %} ### Background Manual revocation is available for any certificate issued by SCEPman - regardless of whether it was automatically enrolled via MDM, manually issued via the Certificate Master, or deployed via the Enrollment REST API. Manual revocation is useful when automatic revocation is not available or when automatic revocation paths are not sufficient to meet specific requirements. To facilitate manual revocation, SCEPman needs to store certain metadata of the certificates it issues. While this is the case by default for certificates issued via the Certificate Master UI and the Enrollment REST API, it is not the case for other certificate types. Therefore, please ensure to review the [relevant settings](#storing-certificate-metadata-in-the-certificate-database) depending on your requirements. Keep reading to learn how manual revocation is handled leveraging Certificate Master and its search and filtering options. ### Certificate Master SCEPman Certificate Master lets you search, inspect, and manage the certificates that your SCEPman PKI has issued: {% content-ref url="/pages/EzTMIeOCNSP2b678IQfD" %} [Manage Certificates](/certificate-management/certificate-master/manage-certificates) {% endcontent-ref %} ## Automatic versus Manual Revocation SCEPman uses different sources of revocation information to determine whether a certificate is valid when an OCSP request arrives. Furthermore, SCEPman's revocation logic follows an **or-ed approach**, which means if any revocation source deems the certificate to be invalid, it will be reported as revoked. There is no precedence from automatic over manual revocation or vice versa. Please note, that the tables in Certificate Master only show the status of manual revocation and not other sources. Therefore, a certificate may be shown as valid in the table, although it is actually considered revoked, for example because the corresponding device was deleted in Intune (automatic revocation). ## Further Reading * Information on how to test (automatic) revocation and troubleshoot certificate validity in some of the above scenarios can be found [here](/other/troubleshooting/general#problems-with-the-validity-of-certificates). * General Information on Azure and M365 device directories can be found [here](/scepman-configuration/device-directories). # Enabling CRL A Certificate Revocation List (CRL) is a record that contains certificates that have been explicitly revoked. {% hint style="danger" %} You do **NOT** need to enable CRL for SCEPman. By default, SCEPman uses OCSP for revocation. {% endhint %} SCEPman primarily relies on OCSP to check a certificates' revocation status as OCSP allows for real time revocation, making it the ideal protocol for dynamic working environments. In contrast, CRL operates on scheduled updates, limiting its effectiveness in time-sensitive scenarios. However, CRL continues to be useful for legacy systems and application or as a fallback when OCSP is not available. {% hint style="warning" %} The CRL will not contain certificates that have been auto-revoked, only certificates that have been explicitly revoked in the Certificate Master {% endhint %} ## Guide {% stepper %} {% step %} ### Navigate to your Environment Variables Azure > App Services > SCEPman App Service (not Certificate Master) > Settings > Environment Variables
{% endstep %} {% step %} ### Add Environment Variables Please note Linux App Service Plans use a double underscore (\_\_) instead of a colon (:). For example: AppConfig\_\_CRL\_\_RequestToken
SettingDescriptionValue
AppConfig:CRL:RequestToken

Defines the URL of the CRL. The CRL is available in both DER and PEM


DER: https://yourscepman.azurewebsites.net/crl/{RequestToken}

PEM: https://yourscepman.azurewebsites.net/crl/pem/{RequestToken}

Example: https://yourscepman.azurewebsites.net/crl/12345678

24 character string
AppConfig:CRL:SourceConnects the CRL to your Azure Storage accountStorage
AppConfig:CRL:AddCdpAdds a CRL Distribution Point to issued certificatestrue
AppConfig:CRL:ValidityDaysThe numbers of days that an issued CRL is validFloating Point
Example 0.1 days = 2.4 hours
{% endstep %} {% step %} ### Apply Environment Variables Press Apply after Environment Variables have been added.
{% endstep %} {% step %} ### Restart SCEPman App Service New Environment Variables are applied after the SCEPman App Service is restarted
{% endstep %} {% step %} ### Test CRL Navigate to your CRL using the previously set Request Token in the format of https\://*yourscepman*.azurewebsites.net/crl/**{RequestToken}**
If setup correctly, your CRL will be downloaded:
{% endstep %} {% step %} ### Use CRL with Applications or Systems Once enabled, ensure your applications or systems are configured to check the CRL during certificate validation to prevent the use of revoked certificates. Some systems allow CRL as a fallback option in the case OCSP is unavailable Other systems **only** allow CRL for revocation such as CBA for Entra, please see our guide here: {% content-ref url="/pages/n9Tix1OmppMKK19BvAcT" %} [Certificate-based Authentication for Entra ID](/scepman-deployment/deployment-guides/scenarios/certificate-based-authentication-for-entra-id) {% endcontent-ref %} {% endstep %} {% endstepper %} # Microsoft Intune {% content-ref url="/pages/-LoGexrI8Xp9OjWsKzUz" %} [Windows](/certificate-management/microsoft-intune/windows-10) {% endcontent-ref %} {% content-ref url="/pages/-MCkO9BAtvI4UPrbFVIX" %} [macOS](/certificate-management/microsoft-intune/macos) {% endcontent-ref %} {% content-ref url="/pages/-MCkO9BC67lZTFXBzPU9" %} [Android](/certificate-management/microsoft-intune/android) {% endcontent-ref %} {% content-ref url="/pages/-MCkO9BBozbZimyPgClS" %} [iOS/iPadOS](/certificate-management/microsoft-intune/ios) {% endcontent-ref %} # Windows Deploy certificates to Windows devices via SCEP in Intune using SCEPman. The following article describes deploying a device or/and user certificates for Windows devices. The deployment of the SCEPman Root Certificate is mandatory. Afterward, you can choose between deploying only the device, user, or even both certificate types. ## Root Certificate The basis for deploying SCEP certificates is to trust the root certificate of SCEPman. Therefore, you have to download the CA Root certificate and deploy it as a **Trusted certificate** profile via Microsoft Intune: * [ ] Download the CA Certificate from SCEPman portal: ![](/files/EfcGLtpCiY5X1RgElPgt) * [ ] Create a profile for **Windows 10 and later** with type **Trusted certificate** in Microsoft Intune: ![](/files/fj764rl8kXo5CnEXx798) * [ ] Upload your previously downloaded **.cer file**. * [ ] Now you can deploy this profile to your devices. Please choose All Users and/or All Devices or a dedicated group for assignment. {% hint style="info" %} Note that you have to use the same group for assigning the Trusted certificate and SCEP profile. Otherwise, the Intune deployment might fail. {% endhint %} ## Device Certificates * [ ] Open the SCEPman portal and copy the URL under Intune MDM ![](/files/vgLLC9xx9JKkFiji3LFa) * [ ] Create a profile for **Windows 10 and later** with type **SCEP certificate** in Microsoft Intune ![](/files/8HUxPcZ8FN4OGvsLSUGl) * [ ] Configure the profile as described:
Certificate type: Device In this case we are setting up a device certificate
Subject name format: CN={{DeviceName}} or CN={{DeviceId}} or CN={{AAD_Device_ID}} **Recommended:** Use `{{DeviceName}}`for the CN RDN to have a meaningful name of the certificate on the device or when searching for the certificate. **Optional:** If configured to `CN={{DeviceId}}` or `CN={{AAD_Device_ID}}`, SCEPman uses the CN field of the subject name to identify the device and as a seed for the certificate serial number generation. Microsoft Entra ID (Azure AD) and Intune offer two different IDs: * `{{DeviceId}}`: This ID is generated and used by Intune.\ \ (requires [Intune Validation](/scepman-configuration/application-settings/scep-endpoints/intune-validation#appconfig-intunevalidation-devicedirectory) to be set to **Intune** or **AADAndIntune**) * `{{AAD_Device_ID}}`: This ID is generated and used by Microsoft Entra ID (Azure AD). In case neither `CN={{DeviceId}}` nor `CN={{AAD_Device_ID}}` is used for the CN field (e.g. `CN={{DeviceName}})`, SCEPman will identify the device based on the Intune Device ID (`(URI)Value:` `IntuneDeviceId://{{DeviceId}}`) provided in the subject alternative name (SAN). {% hint style="info" %} You can specify these variables and static text in the textbox. For example, the common name for a device named *Device1* can be added as **CN={{DeviceName}}YourDomain.com** {% endhint %} **Important:** The choice of the CN field affects the [automatic revocation behavior](/certificate-management/manage-certificates#automatic-revocation) of certificates issued to your Intune-managed devices. You can add other RDNs if needed (e.g.: `CN={{DeviceId}}, O=Contoso, CN={{WiFiMacAddress}}`). Supported variables are listed in the [Microsoft docs](https://docs.microsoft.com/en-us/mem/intune/protect/certificates-profile-scep#create-a-scep-certificate-profile).
Subject alternative name: (URI)Value: IntuneDeviceId://{{DeviceId}} The URI field is [recommended by Microsoft](https://techcommunity.microsoft.com/t5/intune-customer-success/new-microsoft-intune-service-for-network-access-control/ba-p/2544696) for NAC solutions to identify the devices based on their Intune Device ID. The value should be: ``` IntuneDeviceId://{{DeviceId}} ``` The **URI field is mandatory** in case neither `CN={{DeviceId}}` nor `CN={{AAD_Device_ID}}` is used in the **Subject name format** field. Other SAN values like DNS can be added if needed.
Certificate validity period: 1 year The amount of time remaining before the certificate expires. Default is set at one year. SCEPman caps the certificate validity to the configured maximum in setting [***AppConfig:ValidityPeriodDays***](/scepman-configuration/application-settings/certificates#appconfig-validityperioddays), but otherwise uses the validity configured in the request.
Key storage provider (KSP): Enroll to Trusted Platform Module (TPM) KSP, otherwise fail This setting determines the storage location of the private key for the end-user certificates. Storage in the TPM is more secure than software storage because the TPM provides an additional layer of security to prevent key theft. Note: There is **a bug in some older TPM firmware versions** that invalidates some signatures created with a TPM-backed private key. In such cases, the certificate cannot be used for EAP authentication as it is common for Wi-Fi and VPN connections. In addition, this might break your Autopilot onboarding process. Affected TPM firmware versions include: * STMicroelectronics: 71.12, 73.4.17568.4452, 71.12.17568.4100, 73.20.17568.6684 * Intel: 11.8.50.3399, 2.0.0.2060 * Infineon: 7.63.3353.0 * IFX: Version 3.19 / Specification 1.2 * IFX version 7.63.3353.0 specification 2.0 If you use TPM with this firmware, either update your firmware to a newer version or select "Software KSP" as a key storage provider. **Update:** You can workaround the TPM bug by removing the RSA-PSS signature algorithms -that are causing the issue- from the registry, for more information please check [Richard Hicks's article](https://directaccess.richardhicks.com/2023/02/13/always-on-vpn-authentication-failed-reason-code-16/) and [Microsoft Q\&A](https://learn.microsoft.com/en-us/answers/questions/467673/windows-10-tpm-2-0-client-authentication-in-tls-1)
Key usage: Digital signature and Key encipherment Please activate both cryptographic actions. SCEPman automatically sets the Key usage to **Digital signature** and **Key encipherment** and overrides the setting here unless the setting [***AppConfig:UseRequestedKeyUsages***](/scepman-configuration/application-settings/certificates#appconfig-userequestedkeyusages) is set to *true*.
Key size (bits): 2048 SCEPman supports 2048 bits.
Hash algorithm: SHA-2 SCEPman supports SHA-2 algorithm.
Root Certificate: Profile from previous step (Root certificate Profile) Please select the Intune profile from [#Root Certificate](#root-certificate).\ If you are using an [Intermediate CA](/scepman-deployment/intermediate-certificate), you must select the Trusted certificate profile for the Intermediate CA, not the Root CA!
Extended key use: Client Authentication, 1.3.6.1.5.5.7.3.2 Please choose **Client Authentication (1.3.6.1.5.5.7.3.2)** under **Predefined values**. The other fields will be filled out automatically.
Renewal threshold (%): 20 This value defines when the device is allowed to renew its certificate (based on the remaining lifetime of an existing certificate). Please read the note under **Certificate validity period** and select a suitable value that allows the device the renew the certificate over a long period. A value of 20% would allow the device with 1 year valid certificate to start renewal 73 days before expiration.
SCEP Server URLs: Open the SCEPman portal and copy the URL of Intune MDM **Example** ``` https://scepman.contoso.com/certsrv/mscep/mscep.dll ```
### Example
* [ ] Now you can deploy this profile to your devices. Please choose the same group/s for the assignment as for the Trusted certificate profile. ## User Certificates Please follow the instructions of [#Device certificates](#device-certificates) and take care of the following differences:
Certificate type: User In this section we are setting up a user certificate.
Subject name format: CN={{UserName}},E={{EmailAddress}} You can define RDNs based on your needs. Supported variables are listed in the [Microsoft docs](https://docs.microsoft.com/en-us/mem/intune/protect/certificates-profile-scep#create-a-scep-certificate-profile). We recommend to include the username (e.g.: janedoe) and email address (e.g.: ) as baseline setting.
Subject alternative name: (UPN)Value: {{UserPrincipalName}} You must add the User principal name as the Subject alternative name. **Add '{{UserPrincipalName}}' as Subject Alternative Name of type User principal name (UPN).** This ensures that SCEPman can link certificates to user objects in AAD. The setting for 'Subject name format' is freely selectable. Other SAN values like an Email address can be added if needed.
{% hint style="info" %} Based on customer feedback, it appears that some VPN clients (e.g., Azure VPN Client for Virtual WAN) are unable to discover the user certificate when it is stored in the TPM. Try enrolling it to the software KSP instead. {% endhint %} ### Example
## User Digital Signature Certificate You may use SCEPman for transnational **digital signatures** i.e. for S/MIME signing in Microsoft Outlook. If you plan to use the certificates for message signing you need to add the corresponding extended key usages in the Intune profile configuration. {% hint style="warning" %} **Do not** use SCEPman **for email-encryption** i.e. for S/MIME mail encryption in Microsoft Outlook (without a separate technology for key management). The nature of **the SCEP protocol does not include a mechanism to backup or archive private key material.** If you would use SCEP for email-encryption you may lose the keys to decrypt the messages later. {% endhint %} * [ ] You must set these configuration variables otherwise the requested key usage and extended validity period in the SCEP profile are not honored by SCEPman: - [*`AppConfig:UseRequestedKeyUsages`*](/scepman-configuration/application-settings/certificates#appconfig-userequestedkeyusages) set to *`true`* - [*`AppConfig:ValidityPeriodDays`*](/scepman-configuration/application-settings/certificates#appconfig-validityperioddays) *set to `365` (a maximum value of 1825 - 5 years is possible)* To deploy user certificates used for **Digital Signatures** please follow the instructions of [#User certificates](#user-certificates) and take care of the following differences and notes:
Subject alternative name * **(required) User principal name (UPN):** *`{{UserPrincipalName}}`* * **(required) Email address:** *`{{EmailAddress}}`* By deploying a digital signature certificate, you must add the UPN and the email address.
Key usage: only Digital signature
Extended key usage: Secure Email (1.3.6.1.5.5.7.3.4) Please choose **Secure Email (1.3.6.1.5.5.7.3.4)** under **Predefined values**. The other fields will be filled out automatically.
Renewal Threshold (%): 50 We recommend setting Renewal Threshold (%) to a value that ensures certificates are renewed at least 6 months before expiration when issuing S/MIME signature certificates. This is because emails signed with expired certificates are shown to have invalid signatures in Outlook, which confuses users. Having a new certificate long before the old one expires ensures that only older emails show this behavior, which users are more unlikely to look at. For example, if your signature certificates are valid for one year, you should set the Renewal Threshold to at least 50 %.
### **Example**
After a successful profile sync, you should see the user certificate for Intended Purposes **Secure Email** ![](/files/-MWU2A29YdmO9YH0m6NL) The certificate will be available for Digital Signature usage in e.g. Outlook. Below is an example of the usage ![](/files/ByYGzuLeYCwid28SNZqM) ### Activate S/MIME Signatures in Outlook Once you have deployed S/MIME signature certificates to your client machines, you must configure Outlook to use these certificates before sending signed emails. #### New Outlook S/MIME for new Outlook can be set up [manually](https://support.microsoft.com/en-us/office/set-up-outlook-to-use-s-mime-encryption-2e57e4bd-4cc2-4531-9a39-426e7c873e26#id0ebbf=new_outlook). #### Classic Outlook S/MIME for Classic Outlook can be set up [manually](https://support.microsoft.com/en-us/office/set-up-outlook-to-use-s-mime-encryption-2e57e4bd-4cc2-4531-9a39-426e7c873e26#id0ebbf=newer_versions) or quickly setup with our [PowerShell Script](https://github.com/glueckkanja-pki/PKI-Configuration-Tools/blob/master/README.md). #### Outlook on the Web S/MIME for Outlook on the Web can be setup [manually](https://support.microsoft.com/en-us/office/set-up-outlook-to-use-s-mime-encryption-2e57e4bd-4cc2-4531-9a39-426e7c873e26#id0ebbf=web) or enabled using PowerShell this with the following command: ``` Set-SmimeConfig -OWAAllowUserChoiceOfSigningCertificate $true ``` Additional PowerShell commands can be seen [here](https://learn.microsoft.com/en-us/powershell/module/exchange/set-smimeconfig). # macOS Deploy certificates to MacOS devices via SCEP in Intune using SCEPman. The following article describes how to deploy a device or/and user certificates for macOS devices. The deployment of the SCEPman Root Certificate is mandatory. Afterward, you can choose between deploying only device, user or both certificate types. {% hint style="warning" %} Please note that macOS enrolls a separate client authentication certificate(s) for each device configuration profile in which a SCEP profile is referenced, in addition to the actual SCEP certificate profile. See the note [here](https://learn.microsoft.com/en-us/intune/intune-service/protect/certificates-profile-scep#assign-the-certificate-profile) {% endhint %} ## Root Certificate The basis for deploying SCEP certificates is to trust the root certificate of SCEPman. Therefore, you have to download the CA Root certificate and deploy it as a **Trusted certificate** profile via Microsoft Intune: * [ ] Download the CA Certificate from your SCEPman portal: ![](/files/EfcGLtpCiY5X1RgElPgt) * [ ] Create a profile for macOS with type **Trusted certificate** in Microsoft Intune: ![](/files/UFhWtq0dONh5Qy1u4E9U) * [ ] Upload your previously downloaded **.cer file**. * [ ] Now you can deploy this profile to your devices. Please choose All Users and/or All Devices or a dedicated group for assignment. {% hint style="info" %} Note, that you have to use the **same group for assigning** the **Trusted certificate** and **SCEP profile**. Otherwise, the Intune deployment might fail. {% endhint %} ## Device certificates * [ ] Open the SCEPman portal and copy the URL under **Intune MDM**: ![](/files/vgLLC9xx9JKkFiji3LFa) * [ ] Create a profile for macOS with type **SCEP certificate** in Microsoft Intune: ![](/files/PyyysYbccKhzAL1Mz00g) * [ ] Configure the profile as described:
Certificate type: Device In this section we are setting up a device certificate.
Subject name format: CN={{DeviceName}} or CN={{DeviceId}} or CN={{AAD_Device_ID}} **Recommended:** Use `{{DeviceName}}`for the CN RDN to have a meaningful name of the certificate on the device or when searching for the certificate. **Optional:** If configured to `CN={{DeviceId}}` or `CN={{AAD_Device_ID}}`, SCEPman uses the CN field of the subject name to identify the device and as a seed for the certificate serial number generation. Microsoft Entra ID (Azure AD) and Intune offer two different IDs: * `{{DeviceId}}`: This ID is generated and used by Intune.\ \ (requires [Intune Validation](/scepman-configuration/application-settings/scep-endpoints/intune-validation#appconfig-intunevalidation-devicedirectory) to be set to **Intune** or **AADAndIntune**) * `{{AAD_Device_ID}}`: This ID is generated and used by Microsoft Entra ID (Azure AD). In case neither `CN={{DeviceId}}` nor `CN={{AAD_Device_ID}}` is used for the CN field (e.g. `CN={{DeviceName}})`, SCEPman will identify the device based on the Intune Device ID (`(URI)Value:` `IntuneDeviceId://{{DeviceId}}`) provided in the subject alternative name (SAN). **Important:** The choice of the CN field affects the [automatic revocation behavior](/certificate-management/manage-certificates#automatic-revocation) of certificates issued to your Intune-managed devices. You can add other RDNs if needed (e.g.: `CN={{DeviceId}}, O=Contoso, CN={{WiFiMacAddress}}`). Supported variables are listed in the [Microsoft docs](https://docs.microsoft.com/en-us/mem/intune/protect/certificates-profile-scep#create-a-scep-certificate-profile).
Subject alternative name: URI Value:IntuneDeviceId://{{DeviceId}} The URI field is [recommended by Microsoft](https://techcommunity.microsoft.com/t5/intune-customer-success/new-microsoft-intune-service-for-network-access-control/ba-p/2544696) for NAC solutions to identify the devices based on their Intune Device ID. ``` IntuneDeviceId://{{DeviceId}} ``` The **URI field is mandatory** in case neither `CN={{DeviceId}}` nor `CN={{AAD_Device_ID}}` is used in the **Subject name format** field. Other SAN values like DNS can be added if needed.
Certificate validity period: 1 years **Important:** macOS devices ignore the configuration of the validity period via Intune. Please make sure, to configure [Certificates](/scepman-configuration/application-settings/certificates#appconfig-validityperioddays) to a fixed value. You can leave the certificate validity period setting to 1 year because it will be ignored anyway.\ \ **Important:** Also note, that **certificates on macOS are only renewed** by Intune when the device is **unlocked, online, syncing and in scope of the renewal threshold**. If certificates are expired (e.g.: device was offline and/or locked for a long time), they won't be renewed any more. Therefore, we recommend to choose an higher value here.
Key usage: Digital signature and key encipherment Please activate both cryptographic actions.
Key size (bits): 2048 SCEPman supports 2048 bits.
Root Certificate: Profile from previous step Please select the Intune profile from [#Root certificates](#root-certificate)
Extended key usage: Client Authentication, 1.3.6.1.5.5.7.3.2 Please choose **Client Authentication (1.3.6.1.5.5.7.3.2)** under **Predefined values**. The other fields will be filled out automatically. **Important:** macOS devices do not support any Extended Key Usages (EKUs) other than `Client Authentication` . This means that any other EKUs configured in this profile will be ignored.
Renewal threshold (%): 50 This value defines when the device is allowed to renew its certificate (based on remaining lifetime of existing certificate). Please read the note under **Certificate validity period** and select a suitable value that allows the device the renew the certificate over a long period. A value of 50% would allow the device with a 1 years valid certificate to start renewal 182 days before expiration.
SCEP Server URLs: Open the SCEPman portal and copy the URL of Intune MDM **Example** ``` https://scepman.contoso.com/certsrv/mscep/mscep.dll ```
{% hint style="info" %} With our stated settings, we fulfill [Apples certificate requirements](https://support.apple.com/en-us/HT210176). {% endhint %} ### Example
* [ ] Now you can deploy this profile to your devices. Please choose the same group/s for assignment as for the Trusted certificate profile. ## User Certificates The following section will show you how you can deploy user certificates via Intune Certificate profile on macOS X 10.12 (or later) devices. {% hint style="warning" %} Please note: Certificates provisioned through the SCEP protocol - regardless of the type (user or device) - are always placed in the system keychain (System store) of the device. In case a 3rd party application requires access to such a certificate (e.g. 3rd party VPN client), the slider to **Allow all apps access to private key** in the keychain must be set to **enabled**. {% endhint %} Please follow the instructions of [#Device certificates](#device-certificates) and take care of the following differences:
Certificate type: User In this section we are setting up a user certificate.
Subject name format: CN={{UserName}},E={{EmailAddress}} You can define RDNs based on your needs. Supported variables are listed in the [Microsoft docs](https://docs.microsoft.com/en-us/mem/intune/protect/certificates-profile-scep#create-a-scep-certificate-profile). We recommend to include the username (e.g.: janedoe) and email address (e.g.: ) as baseline setting.
Subject alternative name: UPN Value:{{UserPrincipalName}} SCEPman uses the UPN in the SAN to identify the user and as a seed for the certificate serial number generation (e.g.: ).\ \ Other SAN values like Email address can be added if needed.
{% hint style="info" %} With our stated settings, we fulfill [Apples certificate requirements](https://support.apple.com/en-us/HT210176) {% endhint %} ### Example ![](/files/zm6HwTEbkyhzgDPhrjVY) # Android Deploy certificates to Android devices via SCEP using Intune and SCEPman. The following article describes how to deploy a device or a user certificate for Android. Android certificate deployment is similar to Windows 10, macOS, and iOS certificate deployments. {% hint style="info" %} Android provides two distinct solution sets: one is the [work profile](https://developers.google.com/android/work/requirements/work-profile) (known as *Personally-Owned Work Profile)* and the other is the [fully managed device](https://developers.google.com/android/work/requirements/fully-managed-device) (known also as *Fully Managed, Dedicated, and Corporate-Owned Work Profile*). In both scenarios, the settings for certificate configuration profiles remain consistent. {% endhint %} {% hint style="info" %} Android device administrator management was released in Android 2.2 as a way to manage Android devices. Then beginning with Android 5, the more modern management framework of Android Enterprise was released (for devices that can reliably connect to Google Mobile Services). **Google is encouraging movement from device administrator management by decreasing its management support in new Android releases**. For more information please check [MS. Intune Decreasing support for Android device admin](https://techcommunity.microsoft.com/t5/intune-customer-success/decreasing-support-for-android-device-administrator/ba-p/1441935) {% endhint %} ## Root Certificate The basis for deploying SCEP certificates (device or user) is to trust the root certificate of SCEPman. Therefore, you have to download the CA Root certificate and deploy it as a **Trusted certificate** profile via Microsoft Intune: * [ ] Download the CA Certificate from SCEPman portal ![](/files/EfcGLtpCiY5X1RgElPgt) * [ ] Create a profile for Android Enterprise with the type **Trusted certificate** in Microsoft Intune (based on your enrollment option for Android devices)
* [ ] Upload your previously downloaded **.cer file**. * [ ] Now you can deploy this profile to your devices. Please choose All Users and/or All Devices or a dedicated group for the assignment. {% hint style="info" %} Note, that you have to use the **same group for assigning** the **Trusted certificate** and **SCEP profile**. Otherwise, the Intune deployment might fail. {% endhint %} {% hint style="warning" %} Some Android Enterprise deployments require the full Certificate Authority chain (Root CA + Intermediate CA) in the Intune Trusted Certificate profile. This is particularly relevant after Intermediate CA certificate renewals, where deploying only the Root CA may result in SCEP User or WLAN certificate deployment failures. {% endhint %} ## Device Certificates * [ ] Open the SCEPman portal and copy the URL under **Intune MDM**
* [ ] Create a profile for Android Enterprise with type **SCEP certificate** in Microsoft Intune (again, based on your enrollment option for the Android devices)
* [ ] Configure the profile as described
Certificate type: Device In this section, we are setting up a device certificate.
Subject name format: CN={{DeviceId}} or CN={{AAD_Device_ID}} SCEPman uses the CN field of the subject to identify the device and as a seed for the certificate serial number generation. Microsoft Entra ID (Azure AD) and Intune offer two different IDs: * {{DeviceId}}: This ID is generated and used by Intune **(Recommended).** (Requires [#AppConfig:IntuneValidation:DeviceDirectory](/scepman-configuration/application-settings/scep-endpoints/intune-validation#appconfig-intunevalidation-devicedirectory) to be set to **Intune** or **AADAndIntune** * {{AAD\_Device\_ID}}: This ID is generated and used by Microsoft Entra ID (Azure AD). You can add other RDNs if needed (e.g.: `CN={{DeviceId}}, O=Contoso, CN={{WiFiMacAddress}}`). Supported variables are listed in the [Microsoft docs](https://learn.microsoft.com/en-us/mem/intune/protect/certificates-profile-scep#create-a-scep-certificate-profile).
Subject alternative name: URI Value:IntuneDeviceId://{{DeviceId}} ``` IntuneDeviceId://{{DeviceId}} ``` The URI field is [recommended by Microsoft](https://techcommunity.microsoft.com/t5/intune-customer-success/new-microsoft-intune-service-for-network-access-control/ba-p/2544696) for NAC solutions to identify the devices based on their Intune Device ID: Other SAN values like DNS can be added if needed.
Certificate validity period: 1 years The amount of time remaining before the certificate expires. Default is set at one year. SCEPman caps the certificate validity to the configured maximum in setting [***AppConfig:ValidityPeriodDays***](/scepman-configuration/application-settings/certificates#appconfig-validityperioddays), but otherwise uses the validity configured in the request.
Key usage: Digital signature and key encipherment Please activate both cryptographic actions.
Key size (bits): 4096 SCEPman supports 4096 bits.
Root Certificate: Profile from previous step Please select the Intune profile from \[[#root-certificate](#root-certificate "mention")]\(android.md#root-certificate). If you are using an [Intermediate CA](/scepman-deployment/intermediate-certificate), you must still select the Trusted certificate profile for Root CA, not the Intermediate CA!
Extended key usage: Client Authentication, 1.3.6.1.5.5.7.3.2 Please choose **Client Authentication (1.3.6.1.5.5.7.3.2)** under **Predefined values**. The other fields will be filled out automatically.
Renewal threshold (%): 20 This value defines when the device is allowed to renew its certificate (based on the remaining lifetime of an existing certificate). Please read the note under **Certificate validity period** and select a suitable value that allows the device the renew the certificate over a long period. A value of 20% would allow the device with 1 year valid certificate to start renewal 73 days before expiration.
SCEP Server URLs: Open the SCEPman portal and copy the URL of #Intune MDM **Example** ``` https://scepman.contoso.com/certsrv/mscep/mscep.dll ```
### **Example**
## User Certificates Please follow the instructions of [#Device certificates](#device-certificates) and take care of the following differences:
Certificate type: User In this section we are setting up a user certificate.
Subject name format: CN={{UserName}},E={{EmailAddress}} You can define RDNs based on your needs. Supported variables are listed in the [Microsoft docs](https://docs.microsoft.com/en-us/mem/intune/protect/certificates-profile-scep#create-a-scep-certificate-profile). We recommend to include the username (e.g.: janedoe) and email address (e.g.: ) as baseline setting.
Subject alternative name: (UPN)Value: {{UserPrincipalName}} You **must** add the User principal name as the Subject alternative name. **Add '{{UserPrincipalName}}' as Subject Alternative Name of type User principal name (UPN).** This ensures that SCEPman can link certificates to user objects in AAD. Other SAN values like an Email address can be added if needed.
{% hint style="info" %} It is required to have a **Subject alternative name** in the **SCEP Certificate, User Type**. Without a SAN, you have no access to your company's Wi-Fi. {% endhint %} ### **Example**
## Certificate Check To ensure the correct deployment of certificates on your Android device, there are two options: * In newer Android versions (e.g. 14), you can verify certificates (user and trusted certs.) from the **settings** > **security and privacy** * Via 3rd party apps like [X509 Certificate Viewer Tool](https://play.google.com/store/apps/details?id=com.rdupletlabs.certificateviewer) # iOS/iPadOS Deploy certificates to iOS and iPadOS devices via SCEP in Intune using SCEPman. The following article describes how to deploy a device and/or user certificates for iOS and iPadOS devices. The deployment of the SCEPman Root Certificate is mandatory. Afterward, you can choose between deploying only the device, user, or even both certificate types. {% hint style="warning" %} Please note that iOS and iPadOS enroll a separate client authentication certificate(s) for each device configuration profile in which a SCEP profile is referenced, in addition to the actual SCEP certificate profile. See [here](https://learn.microsoft.com/en-us/intune/intune-service/protect/certificates-profile-scep#assign-the-certificate-profile) {% endhint %} ## Root Certificate The basis for deploying SCEP certificates is to trust the root certificate of SCEPman. Therefore, you have to download the CA Root certificate and deploy it as a **Trusted certificate** profile via Microsoft Intune: * [ ] Download the CA Certificate from SCEPman portal: ![](/files/EfcGLtpCiY5X1RgElPgt) * [ ] Create a profile for iOS/iPadOS with type **Trusted certificate** in Microsoft Intune: ![](/files/3Tsykbu9CapmsveN23nH) * [ ] Upload your previously downloaded **.cer file**. * [ ] Now you can deploy this profile to your devices. Please choose All Users and/or All Devices or a dedicated group for assignment. {% hint style="info" %} Note that you have to use the **same group for assigning** the **Trusted certificate** and **SCEP profile**. Otherwise, the Intune deployment might fail. {% endhint %} ## Device certificates * [ ] Open the SCEPman portal and copy the URL under **Intune MDM**: ![](/files/vgLLC9xx9JKkFiji3LFa) * [ ] Create a profile for iOS/iPadOS with type **SCEP certificate** in Microsoft Intune: ![](/files/Gbkw5R4ZVDt7mGbhA5cx) * [ ] Configure the profile as described:
Certificate type: Device In this section we are setting up a device certificate.
Subject name format: CN={{DeviceId}} or CN={{AAD_Device_ID}} SCEPman uses the CN field of the subject to identify the device and as a seed for the certificate serial number generation. Microsoft Entra ID (Azure AD) and Intune offer two different IDs: * {{DeviceId}}: This ID is generated and used by Intune **(Recommended)**\ \ (requires [Intune Validation](/scepman-configuration/application-settings/scep-endpoints/intune-validation#appconfig-intunevalidation-devicedirectory) to be set to **Intune** or **AADAndIntune**) * {{AAD\_Device\_ID}}: This ID is generated and used by Microsoft Entra ID (Azure AD).\ \ (Note: When using Automated Device Enrollment via Apple Business Manager, this ID might change during device setup. If so, SCEPman might not be able to identify the device afterwards. The certificate would become invalid in that case.) You can add other RDNs if needed (e.g.: `CN={{DeviceId}}, O=Contoso, CN={{WiFiMacAddress}}`). Supported variables are listed in the [Microsoft docs](https://docs.microsoft.com/en-us/mem/intune/protect/certificates-profile-scep#create-a-scep-certificate-profile).
Subject alternative name: URI Value:IntuneDeviceId://{{DeviceId}} The URI field is [recommended by Microsoft](https://techcommunity.microsoft.com/t5/intune-customer-success/new-microsoft-intune-service-for-network-access-control/ba-p/2544696) for NAC solutions to identify the devices based on their Intune Device ID. Other SAN values like DNS can be added if needed.
Certificate validity period: 1 years **Important:** iOS/iPadOS devices ignore the configuration of the validity period via Intune. Please make sure, to configure [Certificates](/scepman-configuration/application-settings/certificates#appconfig-validityperioddays) to a fixed value. We recommend 2 years, so you have to set this variable in SCEPman configuration to 730 days. But you can leave the certificate validity period setting to 1 year because Intune ignores it anyway.\ \ **I****mportant:** Also note, that **certificates on iOS/iPadOS are only renewed** by Intune when the device is **unlocked, online, syncing and in scope of the renewal threshold**. If certificates are expired (e.g.: device was offline and/or locked for a long time), they won't be renewed any more. Therefore, we recommend to choose an higher value here.
Key usage: Digital signature and key encipherment Please activate both cryptographic actions.
Key size (bits): 2048 SCEPman supports 2048 bits.
Root Certificate: Profile from previous step Please select the Intune profile from [#root-certificate](#root-certificate "mention").
Extended key usage: Client Authentication, 1.3.6.1.5.5.7.3.2 Please choose **Client Authentication (1.3.6.1.5.5.7.3.2)** under **Predefined values**. The other fields will be filled out automatically. **Important:** iOS/iPadOS devices do not support any Extended Key Usages (EKUs) other than `Client Authentication` . This means that any other EKUs configured in this profile will be ignored.
Renewal threshold (%): 50 This value defines when the device is allowed to renew its certificate (based on remaining lifetime of existing certificate). Please read the note under **Certificate validity period** and select a suitable value that allows the device the renew the certificate over a long period. A value of 50% would allow the device with a 1 years valid certificate to start renewal 182 days before expiration.
SCEP Server URLs: Open the SCEPman portal and copy the URL of Intune MDM **Example** ``` https://scepman.contoso.com/certsrv/mscep/mscep.dll ```
{% hint style="info" %} With our stated settings, we fulfill [Apples certificate requirements](https://support.apple.com/en-us/HT210176). {% endhint %} ### Example ![](/files/Qj5Ux38k4M4z3tJf6PLn) * [ ] Now you can deploy this profile to your devices. Please choose the same group/s for assignment as for the Trusted certificate profile. ## User Certificates Please follow the instructions of [#device-certificates](#device-certificates "mention") and take care of the following differences:
Certificate type: User In this section we are setting up a user certificate.
Subject name format: CN={{UserName}},E={{EmailAddress}} You can define RDNs based on your needs. Supported variables are listed in the [Microsoft docs](https://docs.microsoft.com/en-us/mem/intune/protect/certificates-profile-scep#create-a-scep-certificate-profile). We recommend to include the username (e.g.: janedoe) and email address (e.g.: ) as baseline setting.
Subject alternative name: UPN Value: {{UserPrincipalName}} SCEPman uses the UPN in the SAN to identify the user and as a seed for the certificate serial number generation (e.g.: ).\ \ Other SAN values like Email address can be added if needed.
{% hint style="info" %} With our stated settings, we fulfill [Apples certificate requirements](https://support.apple.com/en-us/HT210176) {% endhint %} ### Example ![](/files/4QOVxXtg3SJrCvxHggdP) # Linux Deploy certificates to Linux devices via SCEP in Intune using SCEPman. {% hint style="warning" %} SCEPman Enterprise Edition only {% endhint %} The following article describes how to deploy a device or/and user certificates for Intune-managed Linux devices. While the Intune endpoint cannot be directly used by Linux clients we can leverage the enrollment REST API through the Intune script capability. See the following guide on how to implement this method. {% content-ref url="/pages/kQFJQWP3IoIXnw6hfV3R" %} [Intune Managed Linux Client](/certificate-management/api-certificates/self-service-enrollment/intune-managed-linux-client) {% endcontent-ref %} # Jamf Pro {% content-ref url="/pages/-MZCl0wEt1YOqRbUgGTX" %} [General Configuration](/certificate-management/jamf/general) {% endcontent-ref %} {% content-ref url="/pages/-M\_MQhg2kYIj6adxDkZi" %} [Computers](/certificate-management/jamf/computers) {% endcontent-ref %} {% content-ref url="/pages/-M\_MQsD3WM6pPDyGhQMo" %} [Devices](/certificate-management/jamf/devices) {% endcontent-ref %} {% content-ref url="/pages/-MeTs9HP6anmcpD8l4CV" %} [Users](/certificate-management/jamf/users) {% endcontent-ref %} # General Configuration SCEPman can be connected to Jamf Pro as an External CA via a SCEPman's dedicated Jamf endpoint allowing enrolled users and devices to obtain certificates. Jamf Pro acts as a SCEP Proxy, proxing communication between SCEPman and Jamf Pro devices. ## Enable Jamf Integration Jamf integration of SCEPman can be easily enabled via the following environment variables on **SCEPman app service**: | Setting | Description | Example | | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------- | | [AppConfig:JamfValidation:Enabled](/scepman-configuration/application-settings/scep-endpoints/jamf-validation#appconfig-jamfvalidation-enabled) | Do you want to use SCEPman with Jamf? | true | | [AppConfig:JamfValidation:RequestPassword](/scepman-configuration/application-settings/scep-endpoints/jamf-validation#appconfig-jamfvalidation-requestpassword) |

Jamf authenticates its certificate requests at SCEPman with this secure password.

Consider adding this as a secret in your SCEPman KeyVault.

| max *32 character password* | | [AppConfig:JamfValidation:ValidityPeriodDays](/scepman-configuration/application-settings/scep-endpoints/jamf-validation#appconfig-jamfvalidation-validityperioddays) (optional) | How many days shall certificates issued via Jamf be valid at most? | 365 | | [AppConfig:JamfValidation:EnableCertificateStorage](/scepman-configuration/application-settings/scep-endpoints/jamf-validation#appconfig-jamfvalidation-enablecertificatestorage) (optional) | Enable this setting to save Jamf certificates in Certificate Master | true or false (default) | ## API Connection SCEPman needs to be connected to the Jamf API to check the status of onboarded clients. This is used for the revocation of certificates. [Refer to the Jamf documentation](https://learn.jamf.com/en-US/bundle/jamf-pro-documentation-current/page/API_Roles_and_Clients.html) on how to create an API role and API client. The API client must have a role with these permissions: * Read Mobile Devices * Read Computers * Read User Please define the following environment variables in your **SCEPman App Service**: | Setting | Description | Example | | --------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | | [AppConfig:JamfValidation:URL](/scepman-configuration/application-settings/scep-endpoints/jamf-validation#appconfig-jamfvalidation-url) | The URL of your Jamf instance | `https://contoso.jamfcloud.com` | | [AppConfig:JamfValidation:ClientID](/scepman-configuration/application-settings/scep-endpoints/jamf-validation#appconfig-jamfvalidation-clientid) | The identifier of the Jamf API client | See [Jamf ClientId](https://learn.jamf.com/en-US/bundle/jamf-pro-documentation-current/page/API_Roles_and_Clients.html#ariaid-title3) | | [AppConfig:JamfValidation:ClientSecret](/scepman-configuration/application-settings/scep-endpoints/jamf-validation#appconfig-jamfvalidation-clientsecret) |

The Client Secret value for the API Client configuration.

Consider adding this as a secret in your SCEPman KeyVault.

| See [Jamf Client Secret](https://learn.jamf.com/en-US/bundle/jamf-pro-documentation-current/page/API_Roles_and_Clients.html#ariaid-title4) | {% hint style="warning" %} Jamf Pro's Classic API supports Bearer Authentication since version 10.35.0. There is a setting to disable the previous authentication method, Basic Authentication, since version 10.36.0. A future Jamf version scheduled for August-December 2022 will remove support for Basic Authentication. SCEPman 2.0 and lower support only Basic Authentication for the Classic API, while SCEPman 2.1 and higher uses Bearer Authentication. In order to use Bearer Authentication, you must upgrade to SCEPman 2.1 or higher. {% endhint %} ## External CA Connection Open Jamf Pro settings and choose "PKI Certificates" under "Global Management": ![](/files/-M_MGXtuYMwK4PUBfvXb) Switch to tab "Management Certificate Template", "External CA" and activate edit mode. Please enable Jamf Pro as "SCEP Proxy for configuration profiles": ![](/files/-M_MI6e0VlVVszSDZW8v) Please fill out the following fields and save the configuration: | Field | Description | Example/Value | | ------------------------ | ------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **URL** |

URL to SCEPman

Do NOT Forget the /jamf at the end

| | | **Name** | name of instance | SCEPman Contoso | | **Subject** | entities following X.500 standard | O=Contoso | | **Challenge Type** | challenge type for verification of certificate issuing | Static | | **(Verify) Challenge** | pre-shared secret (challenge) | defined in SCEPman via [AppConfig](/scepman-configuration/application-settings/scep-endpoints/jamf-validation#appconfig-jamfvalidation-requestpassword) parameter | | Key Size | key size in bits | 2048 | | Use as digital signature | | Yes (if needed) | | Use for key encipherment | | Yes (if needed) | | Fingerprint | Thumbprint of SCEPman CA-Cert (SHA-1) | visible via SCEPman dashboard ("CA Thumbprint") | ![](/files/2jPvy6Bj4thPJotmwVRM) ### Signing Certificate When using an external CA, Jamf requires that you add the CA certificate so Jamf can compare whether the certificates are correctly signed. However, Jamf only allows adding a CA certificate if you also add a signing certificate with a corresponding private key. Jamf uses this signing certificate to sign certificate requests that are sent to SCEPman. However, SCEPman does not evaluate the signature on requests and accepts even unsigned requests (e.g. from Intune), because the request validity stems solely from using the right request challenge password configured in Jamf. {% tabs %} {% tab title="OpenSSL" %} ```shellscript openssl req -x509 -newkey rsa:4096 -keyout tempKey.key -out tempCert.pem -sha256 -days 3650 -nodes -subj "/CN=JAMF Signer Certificate for SCEPman" openssl pkcs12 -export -out SigningCert.pfx -inkey ./tempKey.key -in ./tempCert.pem -passout pass:password # Remove temporary files rm tempKey.key rm tempCert.pem ``` {% endtab %} {% tab title="PowerShell" %} ```powershell $cert = New-SelfSignedCertificate -Subject "CN=JAMF Signer Certificate for SCEPman" -CertStoreLocation "Cert:\CurrentUser\My" -NotAfter (Get-Date).AddYears(10) $pfxBytes = $cert.Export([System.Security.Cryptography.X509Certificates.X509ContentType]::Pfx, "password") [System.IO.File]::WriteAllBytes("c:\temp\jamf.pfx", $pfxBytes) ``` {% endtab %} {% endtabs %} Then click on "Change Signing and CA Certificates" in the External CA configuration of Jamf ![](/files/-McEMKPevTYePpd9Cquv) In the wizard, upload the PFX file with the signing certificate to Jamf when it asks for it (Note: Pkcs#12 and PFX are synonyms). In the next steps, enter the password for the PFX file and confirm the selection of the signing certificate. In the tab "Upload CA Certificate", you must upload the SCEPman CA certificate. You can obtain the SCEPman CA certificate by clicking on the link "Get CA Certificate" on the top right of the homepage of your SCEPman instance. Finally, confirm your changes. # Computers Please follow this guide to distribute certificates to computers (macOS). Before deploying the first certificates via Jamf Pro, follow the [general steps for Jamf Pro](/certificate-management/jamf/general) first. {% hint style="success" %} We strongly recommend configuring all use-case relevant certificate payloads (trusted certificate / SCEP certificate) in a **single** Configuration Profile in Jamf Pro. {% endhint %} ## SCEPman Root Certificate As first step you need to deploy SCEPman root certificate. Download this CA certificate via SCEPman dashboard: ![](/files/EfcGLtpCiY5X1RgElPgt) Add a new "macOS Configuration Profile" and choose "Certificate" as payload. Enter a meaningful name, upload the certificate (for"Select Certificate Option" select "Upload)" and activate "Allow all apps access": ![](/files/-M_MT6s85rWxxt91Ewvt) Distribute that profile to all clients that should get SCEP certificates later. ## Machine Certificate Please add another "macOS Configuration Profile" and choose "SCEP" as payload. Activate "Use the External Certificate Authority settings to enable Jamf Pro as SCEP proxy for this configuration profile" and enter the following information: | Field | Description | Value/Example | | -------------------------- | ----------------------------------------------- | ---------------------------------------------- | | Name | Name/purpose | e.g. "Device Authentication" | | Redistribute Profile | Re-deploys profile for renewal | e.g. "14 days" | | Subject | Subject for certificate, additions are possible | CN=$JSSID,OU=computers,CN=$PROFILE\_IDENTIFIER | | Allow export from keychain | Controls whether the private key is exportable | No | | Allow all apps access | Controls access to the SCEP certificate | Yes | Please adjust other options to your needs.
## Output on the Client Besides reporting on Jamf Pro, you can easily verify the distribution of SCEPman Root Certificate and Device Certificate via "Keychain Access" on the desired client (under "System"): ![SCEPman Root Certificate](/files/-Ma-f_1miOy6oDptbhSj) ![Device Certificate](/files/-Ma-fNiksiwrx_UX9K1I) # Devices Please follow this guide to distribute certificates to devices (e.g.: iOS, iPadOS). Before deploying the first certificates via Jamf Pro, follow the [general steps for Jamf Pro](/certificate-management/jamf/general) first. {% hint style="success" %} We strongly recommend configuring all use-case relevant certificate payloads (trusted certificate / SCEP certificate) in a **single** Configuration Profile in Jamf Pro. {% endhint %} ## SCEPman Root Certificate As first step you need to deploy SCEPman root certificate. Download this CA certificate via SCEPman dashboard: ![](/files/EfcGLtpCiY5X1RgElPgt) Add a new "Mobile Device Configuration Profile" and choose "Certificate" as payload. Enter a meaningful name and upload the certificate (for "Select Certificate Option" select "Upload): ![](/files/-M_MVBvyMgRyRtv-o_l2) ## Device Certificate Please add another "Mobile Device Configuration Profile" and choose "SCEP" as payload. Activate "Use the External Certificate Authority settings to enable Jamf Pro as SCEP proxy for this configuration profile" and enter the following information: | Field | Description | Value/Example | | -------------------- | ----------------------------------------------- | -------------------------------------------- | | Name | Name/purpose | e.g. "Device Authentication" | | Redistribute Profile | Re-deploys profile for renewal | e.g. "14 days" | | Subject | Subject for certificate, additions are possible | CN=$JSSID,OU=devices,CN=$PROFILE\_IDENTIFIER | Please adjust other options to your needs.
# Users Please follow this guide to distribute certificates to users. User certificates are possible on computers (macOS) as well as devices (e.g.: iOS, iPadOS). Before deploying the first certificates via Jamf, follow the [general steps for Jamf Pro](/certificate-management/jamf/general) first. {% hint style="success" %} We strongly recommend configuring all use-case relevant certificate payloads (trusted certificate / SCEP certificate) in a **single** Configuration Profile in Jamf Pro. {% endhint %} {% hint style="info" %} Note that the "User and Location" data of your computers or mobile devices need to be properly populated for user certificates to be issued. In particular, the user must have an email address as this is used as unique identifier. {% endhint %} ## SCEPman Root Certificate As first step you need to deploy SCEPman root certificate if you haven't done this already for the target platform. Download this CA certificate via SCEPman dashboard: ![](/files/EfcGLtpCiY5X1RgElPgt) Add a new "Mobile Device Configuration Profile" and/or "macOS Configuration Profile", depending on your target platform, and choose "Certificate" as payload. Enter a meaningful name and upload the certificate (for "Select Certificate Option" select "Upload): ![](/files/-M_MVBvyMgRyRtv-o_l2) ## User Certificates on Computers {% hint style="info" %} Jamf Pro can only deploy user certificates to **MDM-enabled users**. There are some provisioning/pre-stage scenarios in which such user accounts are not created. For further information, please refer to the [Jamf Pro documentation](https://docs.jamf.com/10.33.0/jamf-pro/administrator-guide/MDM-Enabled_Local_User_Accounts.html). {% endhint %} Under Computers -> Configuration Profiles, please add another "macOS Configuration Profile". Under the General Tab, change the Level to "User Level". On the left side, switch to the "SCEP" tab and configure a new SCEP payload. Activate "Use the External Certificate Authority settings to enable Jamf Pro as SCEP proxy for this configuration profile" and enter the following information: | Field | Description | Value/Example | | ------------------------------ | ----------------------------------------------- | ------------------------------------------------------- | | Name | name/purpose | e.g. "User Authentication" | | Redistribute Profile | re-deploys profile for renewal | e.g. "14 days" | | Subject | subject for certificate, additions are possible | CN=$JSSID,OU=users-on-computers,CN=$PROFILE\_IDENTIFIER | | Subject Alternative Name Type | | RFC 822 Name | | Subject Alternative Name Value | | $EMAIL | Distribute the profile to your users as desired. ## User Certificates on Devices Under Devices -> Configuration Profiles, please add another "Mobile Device Configuration Profile". Keep the level at "Device Level", as User Level currently does not support SCEP. Then, choose "SCEP" as payload On the left side. Activate "Use the External Certificate Authority settings to enable Jamf Pro as SCEP proxy for this configuration profile" and enter the following information: | Field | Description | Value/Example | | ------------------------------ | ----------------------------------------------- | ----------------------------------------------------- | | Name | name/purpose | e.g. "User Authentication" | | Redistribute Profile | re-deploys profile for renewal | e.g. "14 days" | | Subject | subject for certificate, additions are possible | CN=$JSSID,OU=users-on-devices,CN=$PROFILE\_IDENTIFIER | | Subject Alternative Name Type | | RFC 822 Name | | Subject Alternative Name Value | | $EMAIL | Distribute the profile to your clients as desired. # Other MDM Solutions You can use SCEPman to issue certificates via MDM systems other than Intune. You must configure a static challenge password (see [RFC 8894, Section 7.3](https://www.rfc-editor.org/rfc/rfc8894.html#name-challengepassword-shared-se) for the formal specification) in both SCEPman and the MDM system. Virtually all MDM systems support this mode of SCEP authentication. Note however, that this does not provide the same level of security as the authentication mode employed with Intune. The challenge password authenticates requests from the MDM system, so SCEPman knows they come from a trusted source. But if attackers steal the challenge password, they can authenticate any certificate request and make SCEPman issue them whatever certificate they want. It is therefore crucial to keep the challenge password secure. This can be achieved when the MDM system acts as the SCEP client and delivers the final package comprising certificate and private key to the end-user devices. This way, the challenge password is used only available to SCEPman and the MDM system, but not on the end-user devices. ## SCEPman Configuration There are two SCEP endpoints to choose from when configuring SCEPman for MDM systems other than Intune and Jamf Pro: * Static-AAD * Static The Static-AAD endpoint is recommended for MDM systems with Entra ID integration such as Kandji and Google Workspace. *User* certificates distributed from the Static-AAD endpoint will benefit from [Automatic Revocation](/certificate-management/manage-certificates#automatic-revocation) when the respective user has been disabled in Entra ID. The Static endpoint is recommended for all other MDM systems. {% tabs %} {% tab title="Static-AAD" %} Add the following settings to your **SCEPman App Service** > Environment Variables > Add. Once the settings have been added, save the settings and restart your **SCEPman App Service**. | Setting | Description | Value | | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------: | | [AppConfig:StaticAADValidation:Enabled](/scepman-configuration/application-settings/scep-endpoints/staticaad-validation#appconfig-staticaadvalidation-enabled) | Enable Static-AAD validation | ***true*** to enable, ***false*** to disable | | [AppConfig:StaticAADValidation:RequestPassword](/scepman-configuration/application-settings/scep-endpoints/staticaad-validation#appconfig-staticaadvalidation-requestpassword) |

Certificate signing requests sent to SCEPman for signing are authenticated with this secure static password

Recommendation: Store this secret in Azure KeyVault.

| *generate a 32 character password* | |

AppConfig:StaticAADValidation:ValidityPeriodDays

(optional)

| Days certificates issued via the Static-AAD endpoint are valid | 365 | |

AppConfig:StaticAADValidation:EnableCertificateStorage

(optional)

| Store requested certificates in the Storage Account, in order to show them in SCEPman Certificate Master | ***true*** to enable, ***false** to disable* | | {% endtab %} | | | {% tab title="Static" %} Add the following settings to your **SCEPman App Service** > Environment Variables > Add. Once the settings have been added, save the settings and restart your **SCEPman App Service**. | Setting | Description | Value | | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------: | | [AppConfig:StaticValidation:Enabled](/scepman-configuration/application-settings/scep-endpoints/static-validation#appconfig-staticvalidation-enabled) | Enable 3rd-party validation | ***true*** to enable, ***false*** to disable | | [AppConfig:StaticValidation:RequestPassword](/scepman-configuration/application-settings/scep-endpoints/static-validation#appconfig-staticvalidation-requestpassword) |

Certificate signing requests sent to SCEPman for signing are authenticated with this secure static password

Recommendation: Store this secret in Azure KeyVault.

| *generate a 32 character password* | | [AppConfig:StaticValidation:ValidityPeriodDays](/scepman-configuration/application-settings/scep-endpoints/static-validation#appconfig-staticvalidation-validityperioddays) (optional) | Days certificates issued via the Static endpoint are valid | 365 | | [AppConfig:StaticValidation:EnableCertificateStorage](/scepman-configuration/application-settings/scep-endpoints/static-validation#appconfig-staticvalidation-enablecertificatestorage) (optional) | Store requested certificates in the Storage Account, in order to show them in SCEPman Certificate Master | ***true*** to enable, ***false** to disable* | | {% endtab %} | | | | {% endtabs %} | | | ## MDM Configuration The specific steps depend on the MDM system you are using. You must add as SCEP URL somewhere and you must add the challenge password to your MDM system's SCEP configuration. For security reasons, please make your MDM system a SCEP proxy. Note that there are two variants of SCEP proxy implementations, only one of which is secure in this configuration: 1. Your MDM system may act as a SCEP client, generate the secret keypair, and deliver the complete package consisting of certificate and private key to the end-user devices. This is secure, as the challenge password is used only between MDM system and SCEPman. 2. Your MDM system relays SCEP messages between end-user device and SCEPman. The end-user device generates the secret keypair and *adds the challenge password* to the certificate request. This is less secure, as an attacker with control over a single end-user device may steal the challenge password and request all kinds of certificates from SCEPman. Furthermore, the MDM system cannot control whether the client has correctly requested a certificate or whether the certificate request is incorrect, possibly allowing for identity theft or other threats. # Addigy Issue certificates in Addigy by connecting SCEPman as an External CA. Devices will be able to obtain certificates using SCEPman's static interface and a challenge password enrolled. SCEPman can be integrated with [Addigy](https://addigy.com/) as an External Certificate Authority (CA) using SCEPman's static interface. With a configured challenge password, enrolled devices will be able to request and obtain certificates. For more general information about other MDM solutions and SCEPman integration, please check [here](/certificate-management/static-certificates). ## Enable Addigy Integration Integration of SCEPman can be easily enabled via the following environment variables on SCEPman App Service: {% hint style="info" %} You can differentiate between the SCEPman App Service and the Certificate Master by looking for the App Service **without** the "-cm" in its name {% endhint %} | Setting | Description | Value | | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------: | | [AppConfig:StaticValidation:Enabled](/scepman-configuration/application-settings/scep-endpoints/static-validation#appconfig-staticvalidation-enabled) | Enable 3rd-party validation | ***true*** to enable, ***false*** to disable | | [AppConfig:StaticValidation:RequestPassword](/scepman-configuration/application-settings/scep-endpoints/static-validation#appconfig-staticvalidation-requestpassword) |

Certificate signing requests sent to SCEPman for signing are authenticated with this secure static password

Recommendation: Store this secret in Azure KeyVault.

| *generate a 32 character password* | | [AppConfig:StaticValidation:ValidityPeriodDays](/scepman-configuration/application-settings/scep-endpoints/static-validation#appconfig-staticvalidation-validityperioddays) (optional) | Days certificates issued via Addigy are valid | 365 | | [AppConfig:StaticValidation:EnableCertificateStorage](/scepman-configuration/application-settings/scep-endpoints/static-validation#appconfig-staticvalidation-enablecertificatestorage) (optional) | Store requested certificates in the Storage Account, in order to show them in SCEPman Certificate Master | ***true*** to enable, ***false** to disable* | {% hint style="warning" %} After adding or editing SCEPman configuration parameters, you need to restart the App Service. {% endhint %} ## Addigy Configuration ### SCEPman Root Certificate As a first step, SCEPman root certificate must be deployed. To do so, download the RootCA certificate via the SCEPman website: ![SCEPman Website](/files/EfcGLtpCiY5X1RgElPgt) Now convert the .cer root certificate to PEM format in order to upload it to Addigy. You can use the following OpenSSL command for that: ``` openssl x509 -inform der -in scepman-root.cer -out SCEPman-Root-Certificate.pem ``` In Addigy, navigate to **Profiles** and create a new MDM profile, choose **Certificates - (PKCS12)** as Profile Type to upload SCEPman RootCA and upload the PEM format file.
### SCEP Profile The second step is to create a new **SCEP Profile** for device certificate deployment as below: * **Payload Name:** Choose a name for the profile, this will appear as a certificate profile on the client. * **URL**: The static SCEP endpoint of SCEPman that you configured in a previous step, you can get it from SCEPman homepage, see below:
* **Challenge**: Is required to authenticate CSR requests sent to SCEPman's static SCEP interface. It must match the [value](/scepman-configuration/application-settings/scep-endpoints/static-validation#appconfig-staticvalidation-requestpassword) of the setting *AppConfig:StaticValidation:RequestPassword* that you previously configured. * Enable the **"Proxy SCEP Requests"** option * Choose "Signing & Encryption" for **Key Usage** * Fill out the rest as shown in the screenshots below
After successfully creating both the Root CA and Device Certificate profiles, apply them to your policy to deploy the configuration to assigned devices. For more information, please check [Addigy's documentation.](https://support.addigy.com/hc/en-us/articles/4403542430739-Deploying-Certificates) # Google Workspace Learn how to set up and configure certificate enrollment via SCEP for ChromeOS (Chromebook) using Chrome Enterprise and SCEPman. ## Workflow of issuing SCEP Certificates 1. Chromebook generates a hardware-backed private key. 2. Google generates a CSR with the SCEP profile. 3. Connector forwards the CSR to SCEPman. 4. SCEPman signs the CSR and sends the signed CRS back to the connector which forwards it to PubSub. 5. PubSub sends the signed CRS to device management for temporary storage. 6. Device management sends the signed CRS to the Chromebook where it is merged with the harware-backed private key. The signed CSR is deleted from temporary storage. ## Prerequisites ### Google Workspace This guide assumes that you already provisioned Chromebook computer(s) running ChromeOS version 89 or later managed with **Chrome Enterprise**.

Minimum subscriptions required

### Google Cloud Certificate Connector (GCCC) #### **Prerequisites** * The GCCC requires a Windows Server appliance or VM running Windows Server 2016 or later. * The Windows Server instance must have the following network access: * Outbound: HTTP (80) and HTTPS (443). #### **Installation of the GCCC** 1. In your Google **Admin console** (at admin.google.com) > Go to **Menu** > **Devices** > **Network** 2. Click **Secure SCEP** > **Download Connector**. 3. In the **Google Cloud Certificate Connector** section, click **Download**. The download creates a folder on your desktop that contains the certificate connector. We recommend you download the other connector configuration files to this folder. 4. In the **Download the connector configuration file** section, click **Download**. The `config.json` file downloads. 5. In the **Get a service account key** section, click **Generate key**. The `key.json` file downloads. 6. Run the certificate connector installer. 1. In the installation wizard, click **Next**. 2. Accept the terms of the license agreement and click **Next**. 3. Choose the account that the service is installed for and click **Next**. The account must have privileges to sign in as a service on the Windows server. 4. Select the installation location. We recommend using the default. Click **Next**. 5. Enter your service account credentials and click **Next**. The service installs. 6. Click **Finish** to complete the installation. 7. Move the configuration and key files (`config.json` and `key.json`) into the GCCC folder created during installation, typically: `C:\Program Files\Google Cloud Certificate Connector`. 8. Launch the Google Cloud Certificate Connector service: 1. Open Windows Services. 2. Select **Google Cloud Certificate Connector** in the list of services. 3. Click **Start** to start the service. Ensure that the status changes to **Running**. The service automatically restarts if the computer reboots. {% hint style="info" %} If you download a new service account key later, restart the service to apply it. {% endhint %} ### SCEPman Enable Google Workspace Integration by adding the following environment variables on SCEPman app service: {% hint style="info" %} You can differentiate between the SCEPman App Service and the Certificate Master by looking for the App Service **without** the "-cm" in its name {% endhint %} | Setting | Description | Value | | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------: | | [AppConfig:StaticValidation:Enabled](/scepman-configuration/application-settings/scep-endpoints/static-validation#appconfig-staticvalidation-enabled) | Enable 3rd-party validation | ***true*** to enable, ***false*** to disable | | [AppConfig:StaticValidation:RequestPassword](/scepman-configuration/application-settings/scep-endpoints/static-validation#appconfig-staticvalidation-requestpassword) |

Certificate signing requests sent to SCEPman for signing are authenticated with this secure static password

Recommendation: Store this secret in Azure KeyVault.

| *generate a 32 character password* | | [AppConfig:StaticValidation:ValidityPeriodDays](/scepman-configuration/application-settings/scep-endpoints/static-validation#appconfig-staticvalidation-validityperioddays) (optional) | Days certificates issued via Google Workspace are valid | 365 | | [AppConfig:StaticValidation:EnableCertificateStorage](/scepman-configuration/application-settings/scep-endpoints/static-validation#appconfig-staticvalidation-enablecertificatestorage) (optional) | Store requested certificates in the Storage Account, in order to show them in SCEPman Certificate Master | ***true*** to enable, ***false** to disable* | {% hint style="info" %} For more information and references please visit [Google Workspace Admin Help](https://support.google.com/a/answer/9366164?hl=en\&fl=1\&sjid=2941552975651362083-NC) or download the original PDF guide [Configuring Certificate Enrollment for ChromeOS via SCEP](https://support.google.com/chrome/a/answer/11338941?hl=en). *Google, Google Workspace, ChromeOS and related marks and logos are trademarks of Google LLC.* {% endhint %} # ChromeOS This document describes deploying a device and/or user certificates for ChromeOS devices. The deployment of the SCEPman Root Certificate is mandatory. ## Root Certificate As a first step, you must deploy SCEPman's root certificate. Therefore, follow these steps: 1. Download the root CA certificate from your SCEPman website by clicking on the **Get CA Certificate** link.
2. Now upload your SCEPmen root CA to your Google Workplace. In your Google **Admin console** (admin.google.com) navigate to **Menu** > **Devices** > **Networks** > **Certificates** > **ADD CERTIFICATE** {% hint style="warning" %} Be aware that the Google Admin console only accepts certificates in PEM format. You will need to convert SCEPman root CA (which is downloaded in DER by default) using *openssl* or by importing it in Windows and exporting it again in Base-64 format. {% endhint %}
## Add a SCEP Profile The SCEP profile defines the certificate that lets users access your WiFi. Assign the profile to specific users by adding it to an organisational unit. Set up multiple SCEP profiles to manage access by device type. The following configuration example 1. In your Google **Admin console** (admin.google.com) navigate to **Menu** > **Devices** > **Network** 2. Click **Create SCEP Profile**. 3. Click **Add Secure SCEP Profile**. 4. Enter the configuration details for the profile. | Attribute | Value (Device) | Value (User) | | -------------------- | ------------------- | ----------------- | | **Device platforms** | Chromebook (device) | Chromebook (user) |
| Attribute | | | --------------------- | ------------------------------------- | | **SCEP profile name** | Provide a name for your SCEP profile. |
AttributeValue (Device)Value (User)
Subject name formatFully distinguished nameFully distinguished name
Common name: ${DEVICE_SERIAL_NUMBER}Common name: ${USER_EMAIL}
Company name: Your company name.Company name: Your company name.
Organisation unit: Your organizational unit. This is optional.Organisation unit: Your organizational unit. This is optional.
Locality: Your organisation unit's location. This is optional.Locality: Your organisation unit's location. This is optional.
State: Your organisation unit's state. This is optional.State: Your organisation unit's state. This is optional.
Country / region: Your organisation unit's country. This is optional.Country / region: Your organisation unit's country. This is optional.
Subject alternative nameDefault: None

This can be set to Custom when the SAN shall be used, e.g. as outer identity when authenticating to a WiFi using EAP-TLS.

Custom

User Principal: ${USER_EMAIL_NAME}

| Attribute | Value | | --------------------- | ------------------------------------------ | | **Signing algorithm** | SHA256withRSA | | **Key usage** | Key encipherment, Signing | | **Key size (bits)** | 3072 | | **Security** | Strict (only supported by managed devices) |
AttributeValue
SCEP server attributesSCEP server URL: http://scepman.yourdomain.net/static
Certificate validity period (years): 1
Renew within days: 42
Extended key usage: Client authentication
Challenge type: Static
Challenge: Provide the challenge value you have configured when enabling the SCEPman Google Workspace integration.
Certificate Authority: Reference here the certificate profile containing your SCEPman Root CA.
Network type this profile applies to: Wi-Fi
5. The SCEP profile is automatically distributed to users in the organisational unit. 6. To check for this certificate, in your Chromebook navigate to **chrome://certificate.manager** > **Your certificates.**
# Kandji Issue certificates in Kandji by connecting SCEPman as an External CA. Devices will be able to obtain certificates using SCEPman's static interface and a challenge password enrolled. SCEPman can be connected to [Kandji](https://www.kandji.io/) as an External CA via SCEPman's static interface, and a challenge password enrolled devices will be able to obtain certificates. For more general information about other MDM solutions and SCEPman integration, please check [here](/certificate-management/static-certificates). ## Enable Kandji Integration Integration of SCEPman can be easily enabled via the following environment variables on SCEPman App Service: {% hint style="info" %} You can differentiate between the SCEPman App Service and the Certificate Master by looking for the App Service **without** the "-cm" in its name {% endhint %} | Setting | Description | Value | | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------: | | [AppConfig:StaticValidation:Enabled](/scepman-configuration/application-settings/scep-endpoints/static-validation#appconfig-staticvalidation-enabled) | Enable 3rd-party validation | ***true*** to enable, ***false*** to disable | | [AppConfig:StaticValidation:RequestPassword](/scepman-configuration/application-settings/scep-endpoints/static-validation#appconfig-staticvalidation-requestpassword) |

Certificate signing requests sent to SCEPman for signing are authenticated with this secure static password

Recommendation: Store this secret in Azure KeyVault.

| *generate a 32 character password* | | [AppConfig:StaticValidation:ValidityPeriodDays](/scepman-configuration/application-settings/scep-endpoints/static-validation#appconfig-staticvalidation-validityperioddays) (optional) | Days certificates issued via Kandji are valid | 365 | | [AppConfig:StaticValidation:EnableCertificateStorage](/scepman-configuration/application-settings/scep-endpoints/static-validation#appconfig-staticvalidation-enablecertificatestorage) (optional) | Store requested certificates in the Storage Account, in order to show them in SCEPman Certificate Master | ***true*** to enable, ***false** to disable* | {% hint style="warning" %} After adding or editing SCEPman configuration parameters, you need to restart the App Service. {% endhint %} ## Kandji Configuration ### SCEPman Root Certificate As a first step, you must deploy SCEPman's root certificate. Download this CA certificate via the SCEPman website: ![SCEPman Website](/files/EfcGLtpCiY5X1RgElPgt) In Kandji, navigate to **Library** on the left navigation bar and add a **Certificate Library Item** to your Blueprint.

Configure a Certificate Payload

To upload the certificate, first select **PKCS #1-formatted certificate** under **Certificate type**, secondly provide an optional name, upload your SCEPman CA certificate, and eventually save it.

Adding the SCEPman Root CA Certificate

### SCEP Profile The second step is to add a **SCEP Profile** to your **Blueprint**. Therefore, add a new **SCEP Library Item** and configure it as below: * **URL**: The static SCEP endpoint of SCEPman you configured [above](#enable-kandji-integration) * **Name:** An optional SAN attribute * **Challenge**: Is required to authenticate CSR requests sent to SCEPman's static SCEP interface. It must match the [value](/scepman-configuration/application-settings/scep-endpoints/static-validation#appconfig-staticvalidation-requestpassword) you have configured [above](#enable-kandji-integration). * **Fingerprint:** Optional CA fingerprint. It is highly recommended to configure this value as it provides an additional level of security. You can find it on your SCEPman website as **CA Thumbprint**. * **Subject:** Optional subject name. **CN=$PROFILE\_UUID** will be automatically added from Kandji as default common name. Kandji allows you to add multiple CNs. {% hint style="warning" %} We have seen cases where macOS and iOS had problems in auto-selecting client certificates for network authentication purposes where more than two CNs were added. {% endhint %} * **Key Size:** 2048 * **Key Usage:** Both, signing and encryption For more information, please check [Kandji's documentation](https://support.kandji.io/support/solutions/articles/72000559782-scep-profile).

Adding a SCEP Profile

SCEP Profile Configuration

SCEP Profile Configuration

SCEP Profile Configuration

### Deployment Status After saving the certificate or SCEP profile, switch to **Status** to check the deployment status on **Blueprints** assigned devices.

Deployment Status

# Mosyle Issue certificates in Mosyle by connecting SCEPman as an External CA. Devices will be able to obtain certificates using SCEPman's static interface and a challenge password enrolled. For more general information about other MDM solutions and SCEPman integration please check [here](/certificate-management/static-certificates). ## Enable Mosyle Integration Integrating Mosyle with SCEPman can be easily enabled via the following SCEPman app configurations: {% hint style="info" %} You can differentiate between the SCEPman App Service and the Certificate Master by looking for the App Service **without** the "-cm" in its name {% endhint %} | Setting | Description | Value | | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------: | | [AppConfig:StaticValidation:Enabled](/scepman-configuration/application-settings/scep-endpoints/static-validation#appconfig-staticvalidation-enabled) | Enable the 3rd-party validation | **true** to enable, **false** to disable | | [AppConfig:StaticValidation:RequestPassword](/scepman-configuration/application-settings/scep-endpoints/static-validation#appconfig-staticvalidation-requestpassword) |

Certificate signing requests sent to SCEPman for signing are authenticated with this secure static password

Recommendation: Store this secret in Azure KeyVault.

| *generate a 32 character password* | | [AppConfig:StaticValidation:ValidityPeriodDays](/scepman-configuration/application-settings/scep-endpoints/static-validation#appconfig-staticvalidation-validityperioddays) (optional) | How many days shall certificates issued via Mosyle be valid | 365 | | [AppConfig:StaticValidation:EnableCertificateStorage](/scepman-configuration/application-settings/scep-endpoints/staticaad-validation#appconfig-staticaadvalidation-enablecertificatestorage) (optional) | Store requested certificates in the Storage Account, in order to show them in SCEPman Certificate Master | ***true*** to enable, ***false** to disable* | {% hint style="info" %} After adding or editing SCEPman configuration parameters, you need to restart the app service. {% endhint %} ## Mosyle Configuration ### SCEPman Root Certificate As a first step you must deploy SCEPman's root certificate. Download this CA certificate via SCEPman website: ![SCEPman Website](/files/EfcGLtpCiY5X1RgElPgt) In Mosyle, navigate to Management and add "**Multi-Cert Profile**" as a new profile type (if it does not already exist). Now **Add new profile,** choose a name for this profile, e.g. SCEPman Root CA, then click on **+ADD PROFILE** under Profile Name (see screenshot below)**,** and choose "Add Certificate profile" from the shown window. Next, select and upload the SCEPman root certificate you already download, add SCEPman Root CA as Profile Name and Save. ![Adding a Root CA Profile](/files/gTD8wbQRKKAYhj1XFxjl) ![Upload Root CA](/files/Ky45uxqykowZYJnLUFJ9) Now you need to assign this profile to your devices/users, then Save ![Save Root CA profile](/files/7cdlNJ6wz2FDI5MKfJbJ) After saving, you can check the compliance status by clicking on view details on the profile ![Profile Distribution Status](/files/9NwpOedMSVlsHyIbg56A) ### Device Certificate Add a new profile, add profile name e.g. SCEPman Device Certificate, **+ADD PROFILE,** now choose **SCEP Profile** and fill out the values as shown below ![SCEP Profile Configuration](/files/ynh6XmiM12IuqeZEeAgC) ![SCEP Profile Configuration](/files/vTEJ9KFXfAFGsuzhFjFI) **Profile Name:** choose a name for your profile **Server:** choose URL **URL:** past your SCEPman URL with **/static** at the end as shown on the screenshot. You can also copy this value from SCEPman homepage near **Static MDM** **Subject:** It is up to you which variables you choose for the subject, you can choose one or multiple Relative Distinguished Name (RDN). NOTE that RDNs always start with **/** for example `/CN=%DeviceName%` for device name. On our example on the screenshot, we have added 3 RDNs, multiple CNs is also allowed. You can check the variable list by clicking on **View available variables** above the field. **Subject Alternative Name** is optional. **Challenge:** add your 32 character challenge password configured in SCEPman configuration, [see enable Mosyle integration](#enable-mosyle-integration) **Key Size:** 2048 Enable the two options "**Use for signing**" and "**Use for encryption**", and leave all other settings as default (like shown on the screenshot) then **Save** Now you need to assign this profile to your devices/users, then **Save**. After saving, you can check the compliance status by clicking on view details on the profile ![Profile Distribution Status](/files/Gpx0ZlXJCol7G4UOaTET) # SOTI MobiControl SCEPman can be integrated with SOTI MobiControl as a Certificate Authority. By connecting both systems through SCEPman's Static SCEP interface, MobiControl-enrolled devices can obtain device certificates from SCEPman. For more general information about other MDM solutions and SCEPman integration please check [here](/certificate-management/static-certificates). ## Enable SOTI MobiControl Integration SOTI MobiControl integration of SCEPman can be easily enabled via the following environment variables on SCEPman app service: {% hint style="info" %} You can differentiate between the SCEPman App Service and the Certificate Master by looking for the App Service **without** the "-cm" in its name {% endhint %} | Setting | Description | Value | | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------: | | [AppConfig:StaticValidation:Enabled](/scepman-configuration/application-settings/scep-endpoints/static-validation#appconfig-staticvalidation-enabled) | Enable the 3rd-party validation | **true** to enable, **false** to disable | | [AppConfig:StaticValidation:RequestPassword](/scepman-configuration/application-settings/scep-endpoints/static-validation#appconfig-staticvalidation-requestpassword) |

Certificate signing requests sent to SCEPman for signing are authenticated with this secure static password

Recommendation: Store this secret in Azure KeyVault.

| *generate a 32 character password* | | [AppConfig:StaticValidation:ValidityPeriodDays](/scepman-configuration/application-settings/scep-endpoints/static-validation#appconfig-staticvalidation-validityperioddays) (optional) | How many days shall certificates issued via SOTI MobiControl be valid | 365 | | [AppConfig:StaticValidation:EnableCertificateStorage](/scepman-configuration/application-settings/scep-endpoints/staticaad-validation#appconfig-staticaadvalidation-enablecertificatestorage) (optional) | Store requested certificates in the Storage Account, in order to show them in SCEPman Certificate Master | ***true*** to enable, ***false** to disable* | ## SOTI MobiControl Configuration ### Deploy SCEPman RootCA First, you need to deploy SCEPman RootCA to all endpoints as a trusted root ca, you can download the certificate from SCEPman homepage:
### Add Certificate Authority 1. In Soti MobiControl, navigate to System Settings > Global Settings > Services > Certificate Authority.

Soti MobiControl Certificate Authority Page

2. Click the Add button to create a new Certificate Authority.

Soti MobiControl Certificate Authority Details

* Enter a **name** for this Certificate Authority. * Select `Generic SCEP` for **Certificate Type**. * Select `SCEP` for **Configuration Type**. * For the **Service URL**, Copy and Paste the Static MDM URL from your SCEPman Portal. * Enable **Use Static Challenge**. * Enter the **Static Challenge** that was created during Step 2. above. * Enable **Use SCEP Client**. * For the **Thumbprint** Copy and Paste the CA Thumbprint from your SCEPman Portal. * Set the **Retries** and **Retry Delay** as desired (or leave at Default). ### Add Certificate Template 3. Click the Add button to add a **Certificate Template**.

Soti MobiControl Certificate Template Detail

* Enter a **name** for this MobiControl Template. * Enter a **Subject Name**. {% hint style="info" %} The format for the **Subject Name** field can only be the following format: “CN=%DEVICENAME%". Clicking the gear selection will display all of the variables that can be used. Be sure to include the “CN=” at the beginning of the entry. {% endhint %} * Leave **Alternative Subject** empty. * **Certificate Target** defaults to `Device`. * Select the desired option for the remaining fields: **Certificate Usage**, **Key Size**, **Remove old certificates upon successful renewal**, and **Key Protection**. * Click Add, then Save to save the Template 4. Click **Save** to save the Certificate Authority. 5. **Create a Profile** in Soti MobiControl to assign this to your devices. There are multiple ways of achieving this in Soti MobiControl, as such, this document will not detail those methodologies. # Certificate Master {% hint style="warning" %} SCEPman Enterprise Edition only {% endhint %} Certificate Master is the second App Service within every SCEPman deployment, identifiable by the "-cm" designation in the App Service name (unless modified). Below sites provide detailed information on how to issue certificates through the Certificate Master UI for common use cases. ## Getting Started To make use of Certificate Master you will need to assign the intended role first to your user account. Please refer to the following article regarding Certificate Masters role based access control: {% content-ref url="/pages/YCeg2omWp8sx2tlT8hd4" %} [Certificate Master RBAC](/scepman-configuration/rbac) {% endcontent-ref %} ## Certificate Master homepage:
## Quick Overview {% embed url="" %} SCEPman Certificate Master Quick Overview {% endembed %} # Manage Certificates SCEPman Certificate Master lets you search, inspect, and manage the certificates that your SCEPman PKI has issued. It uses two different databases as backend: * A data table in the Azure Storage Account deployed with SCEPman, and * Intune's database of issued certificates. Depending on whether you enrolled a certificate via the Intune MDM or through other means (e.g. [manually with Certificate Master](/certificate-management/certificate-master) or for [Domain Controllers](/certificate-management/domain-controller-certificates)), you should search in one table or the other. You can reach both of them via the navigation bar on the left-hand side of the Certificate Master web UI. {% hint style="info" %} It takes up to 6 hours after enrolling a certificate via Intune until it appears in the list of Intune certificates due to delays in the Intune API. {% endhint %} ### Storing Certificate Metadata in the Certificate Database SCEPman 2.3 and above allows storing certificates issued via one of the SCEP endpoints in the Storage Account. This can be configured per endpoint: * [Jamf](/scepman-configuration/application-settings/scep-endpoints/jamf-validation#appconfig-jamfvalidation-enablecertificatestorage) * [Static](/scepman-configuration/application-settings/scep-endpoints/static-validation#appconfig-staticvalidation-enablecertificatestorage) * [Static-AAD](/scepman-configuration/application-settings/scep-endpoints/staticaad-validation#appconfig-staticaadvalidation-enablecertificatestorage) * [DC](/scepman-configuration/application-settings/scep-endpoints/dc-validation#appconfig-dcvalidation-enablecertificatestorage) Only certificates issued after enabling this setting will be stored in the database, and can be found and revoked manually! ### Search for Certificates in the Certificate Database If you are in the Manage Certificates view in Certificate Master, you will see a table of certificates and some filtering options above the table. Texts entered into the **Search Box** filters certificates with a full-text search in everything shown in the UI, e.g. the certificate serial number, thumbprint, Subject, Subject Alternative Names, and the original requester of the certificate. For the remaining filters, there is the standard view that suits most use cases and allows quick and intuitive selection of filters. If you want to view a more specific set of certificates, you can enable the **advanced filter** to see additional filter options. The **Type of certificate** filter is only visible when the advanced filter option is enabled. It allows to show certificates of specific types, which primarily determines to which type of MDM entity their validity is bound to: * *Static* certificate have no automatic revocation. These are certificates issued via the [Static SCEP Endpoint](/certificate-management/static-certificates) or via [Certificate Master](/certificate-management/certificate-master). * [Domain Controllers](/certificate-management/domain-controller-certificates) receive certificates of type *DC*. * *User* certificates are bound to AAD or Jamf user objects. If these objects are disabled or deleted, or the AAD User Risk is too high, the corresponding certificate will become invalid. * *Device* certificates are bound to AAD or Intune device objects or to Jamf computer or device objects. Deleting or disabling these objects automatically revokes these certificates. If enabled, certificates of this type also become temporarily revoked if the linked directory object get incompliant. The **Validity status** filter lets you display only certificates whose ValidTo date lies in the past (*Expired*), that have been *revoked* manually, or that are within its validity range and not manually revoked (*Valid*). Automatic revocation does not count for this filter, e.g. a device certificate whose device was deleted in AAD, but not manually revoked will show up only if you select Valid (or Any), although it is actually revoked and cannot be used. {% hint style="info" %} The *Revoked Intune Certificates* table in Certificate Master is only relevant if you manually revoke Intune-issued certificates or if Intune has revoked the certificates, for example, due to a pending wipe or other conditions. {% endhint %} You can also filter for the channel the the certificate was enrolled over with the filter **Source of the certificate request**. The specific settings have the following meanings. * *Certificate Master* comprised the certificates manually issued via the Certificate Master web UI. * *REST* are the certificates enrolled via the [SCEPman REST API](/certificate-management/api-certificates). * *SCEP* are all certificates issued over one of the SCEP endpoints, but only if the certificate storage has been enabled on this SCEP endpoint. It also includes certificates that have been enrolled over Intune AND manually revoked. * *SCEP (Generic)* are certificates enrolled via the SCEP endpoints Static, Static-AAD, and Domain Controller. This is and advanced filter and is selectable only when advanced filter is enabled. * *SCEP (Jamf)* are certificates enrolled via the Jamf MDM. This is and advanced filter and is selectable only when advanced filter is enabled. # Certificate Signing Request (CSR) {% hint style="warning" %} SCEPman Enterprise Edition only {% endhint %} Many appliances, web services, and tools offer the option to generate a key pair and a Certificate Signing Request (CSR). The CSR is similar to an X.509 certificate, but lacks the signature of a CA. It does contain a Subject and may contain X.509 extensions like Key Usages, Extended Key Usages, or Basic Constraints. A CA may modify or add any of these properties when issuing a certificate based on a CSR. As an alternative to the CSR, you may [generate a certificate including the private key ](/certificate-management/certificate-master/tls-server-certificate-pkcs-12)with Certificate Master as well. When submitting a CSR via SCEPman Certificate Master, the Subject is carried over as is to the certificate. The following extensions are carried over: * Subject Alternative Names (SANs) * Key Usage * Extended Key Usage SCEPman discards any other extensions from the CSR. Some extensions are added to every certificate like Basic Constraints (denoting that it is a leaf certificate), Authority Information Access (AIA), Authority Key Identifier, and Subject Key Identifier. If you have a CSR at hand, navigate to **Submit CSR** in the SCEPman Certificate Master top menu. You can copy and paste the CSR in PEM format (i.e. text) into the text box, or drag and drop the CSR file in binary or PEM format into the grey area at the bottom. You may use the Browse link as well to select a CSR file in binary and PEM format. When using the text box, you have to hit the Submit button afterward to issue the certificate, while uploading a CSR file immediately issues the certificate. Your browser will download the certificate in DER-encoded format.
# TLS Server Certificate {% hint style="warning" %} SCEPman Enterprise Edition only {% endhint %} You can generate X.509 server certificates including a private key via the SCEPman Certificate Master Web UI. This option allows you to easily generate a TLS certificate for multiple domain names. These certificates can then be used for web servers to enable communication via HTTPS or directory servers to enable LDAPS. Furthermore, they can be used on Active Directory Domain Controllers, but for Domain Controllers, you also have the option to issue special [Domain Controller Certificates](/certificate-management/domain-controller-certificates), which in turn can be used for LDAPS. {% hint style="warning" %} Be aware that once you navigate away from this page, the password will no longer be accessible. {% endhint %} ### Issuing a Server Certificate using a Certificate Signing Request Submit a Certificate Signing Request (CSR) obtained from your appliance or server or created with an external tool like OpenSSL. 1. Paste a plaintext Certificate Signing Request OR paste a CSR file. 2. Submit and download the Server Certificate.

Submit a CSR for a Server Certificate

### Issuing a Server Certificate using the Form This form allows you to create a key pair (private and public key) and associated certificate and download it in a password-protected file. You can copy the file to your server or appliance and install it using the password supplied on this page. Please enter the DNS names over which clients can access your server. They must match, so the clients can establish a TLS connection (like HTTPS/LDAPS/FTPS) without warning. The first Subject Alternative Name (SAN) constitutes the Common Name (CN) of the certificate's subject. 1. Navigate to **New Server Certificate** in the SCEPman Certificate Master top menu 2. Enter all Fully Qualified Domain Names (FQDNs) that the certificate shall be valid for separated by commas, semicolons, or line breaks. These entries will be added as DNS entries to the Subject Alternative Names extension of the certificate. 3. Hit **Submit** once you have entered all domain names and the browser will automatically download the certificate with the private key in PKCS#12/PFX format after the certificate was issued a few seconds later. The PKCS#12 file is encrypted with the password shown on the screen. You can import the PKCS#12 directly to the system where it is needed using the password. Optionally, for mutual authentication scenarios (e.g. mTLS), you can select to include the **Client Authentication** EKU in the certificate.
Some systems can import a certificate with the private key, but do not accept PKCS#12. You can convert the PKCS#12 file to other formats using standard tools like OpenSSL. For example, if your target system requires a PEM file with the certificate and private key, you may use this command: ```shell openssl pkcs12 -in INFILE.p12 -out OUTFILE.crt ``` # TLS Inspection (Sub CA) Certificate {% hint style="warning" %} SCEPman Enterprise Edition only {% endhint %} {% hint style="info" %} This feature requires version **2.4** or above {% endhint %} In some use cases, you may need to issue a Sub CA of SCEPman RootCA (e.g. for a firewall to inspect TLS traffic), in this form, you can manually generate a Sub CA with **Server Authentication** as EKU. The PKCS#12 file is encrypted with the password shown on the screen. You can import the PKCS#12 directly to the system where it is needed using the password. {% hint style="warning" %} Be aware that once you navigate away from this page, the password will no longer be accessible. {% endhint %}
# Code Signing Certificate {% hint style="warning" %} SCEPman Enterprise Edition only {% endhint %} {% hint style="info" %} This feature requires version 2.4 or above {% endhint %} You can manually generate X.509 code signing certificates including a private key via the SCEPman Certificate Master Web UI. This form will generate a code signing certificate based on the provided information and download it in the selected file format. The certificate can be used for code signing purposes, ensuring the integrity and authenticity of software or code by associating it with a trusted entity. ### Issuing a new Code Signing certificate 1. Navigate to **Code Signing** in the SCEPman Certificate Master menu. 2. Enter a Subject CN for the certificate. 3. Hit **Submit** and the browser will automatically download the certificate with the private key in PKCS#12/PFX format after the certificate is issued a few seconds later. The PKCS#12 file is encrypted with the password shown on the screen. {% hint style="warning" %} Be aware that once you navigate away from this page, the password will no longer be accessible. {% endhint %}

Certificate Master - New Code Signing Certificate

# Device Certificate {% hint style="warning" %} SCEPman Enterprise Edition only {% endhint %} {% hint style="info" %} This feature requires version **2.1** or above {% endhint %} You can manually generate X.509 client certificates including a private key via the SCEPman Certificate Master Web UI. This allows you to enroll certificates to smaller numbers of client devices that aren't managed in any MDM system. Generated certificates will have the EKU **Client Authentication** and no Subject Alternative Name (SAN). ### Issuing a Client Certificate 1. To generate a new Device Certificate, navigate to **Device** in the SCEPman Certificate Master menu. 2. Enter a Subject CN for the certificate. 3. Hit **Submit** and the browser will automatically download the certificate with the private key in PKCS#12/PFX format after the certificate is issued a few seconds later. The PKCS#12 file is encrypted with the password shown on the screen. You can import the PKCS#12 directly to the system where it is needed using the password. {% hint style="warning" %} Be aware that once you navigate away from this page, the password will no longer be accessible. {% endhint %}

Certificate Master - New Client Certificate

Some systems can import a certificate with the private key, but do not accept PKCS#12. You can convert the PKCS#12 file to other formats using standard tools like OpenSSL. For example, if your target system requires a PEM file with the certificate and private key, you may use this command: ```shell openssl pkcs12 -in INFILE.p12 -out OUTFILE.crt ``` # User Certificate {% hint style="warning" %} SCEPman Enterprise Edition only {% endhint %} {% hint style="info" %} This feature requires version 2.4 or above {% endhint %} You can manually generate X.509 user certificates including a private key via the SCEPman Certificate Master Web UI. Those certificates can be used in various certificate-based authentication (CBA) scenarios, for smart cards and email signatures. By default, generated certificates will have the EKU **Client Authentication** and a Subject Alternative Name (SAN) set to a UPN-type property where the value matches the UPN provided in the UI. ### Issuing a User Certificate 1. Navigate to **New User Certificate** in the SCEPman Certificate Master menu. 2. Enter a UPN for the certificate and select the required EKUs. 3. Hit **Submit** and the browser will automatically download the certificate with the private key in PKCS#12/PFX format after the certificate is issued a few seconds later. The PKCS#12 file is encrypted with the password shown on the screen. You can import the PKCS#12 directly to the system where it is needed using the password. {% hint style="warning" %} Be aware that once you navigate away from this page, the password will no longer be accessible. {% endhint %}

Certificate Master - New User Certificate

## YubiKey Perform below steps to enroll a smart card certificate to your YubiKey device. ### Checklist: Prerequisites * [ ] *Mandatory* - Access to Certificate Master and a suitable role (`Admin.Full` , `Request.All`,`Request.User`) * [ ] *Mandatory* - Access to a YubiKey device with a free smart card slot * [ ] *Mandatory* - YubiKey Manager is installed ### Steps 1. Open the Certificate Master web portal and click on the **+** icon 2. Select **New User Certificate** 3. Specify the **UPN** as per your requirements 4. Set the **Key Length** to **2048** bits (YubiKey currently does not support 4096-bit keys). 5. Select **PKCS#12** as **Download file format** 6. Select **Client Authentication** and **Smart card Logon** from the **Extended Key Usages**
1. Before clicking **Submit**, ensure to take temporary note of the **Password** as it will be required when importing the certificate to the YubiKey. 2. Open the YubiKey Manager 3. Navigate to **Applications** **>** **PIV** and click **Configure Certificates**
4. Select **Authentication (Slot 9a)** and click **Import** 5. Upload the certificate that was previously generated from Certificate Master and provide the **Password**. 6. Set a **Management key** and click **OK**
# Domain Controller Certificates {% hint style="info" %} This feature requires version **1.6** or above. {% endhint %} {% hint style="warning" %} SCEPman Enterprise Edition only {% endhint %} You can use SCEPman to issue Kerberos authentication certificates to your domain controllers. This allows your AAD or hybrid-joined devices to authenticate seamlessly when accessing on-premises resources. This can be used to implement the **Hybrid Key trust for Windows Hello for Business**. The SCEPman will replace the requirement of a **Public key infrastructure**. Details can be found [here](https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-prereqs) ## Root CA without Enhanced Key Usage (EKU) Extension **This feature has new requirements to the Root CA.**\ If you are updating from an earlier version as **1.6** you must generate a **new** Root CA.\ To support Kerberos authentication certificates the CA certificate must contain either no Enchanced Key Usage (EKU) extension or it must include Kerberos Authentication and Smart Card Logon. If you are starting with SCEPman **1.6** and generating the Root CA with our SCEPman, you can skip the following steps.\ Otherwise please follow this guide to generate a new Root CA. {% hint style="warning" %} If you generate a new CA certificate you must update your Intune policies and deploy the new Root CA and new User and Device certificates! {% endhint %} 1. Navigate to your **Key Vault** 2. Check if your User Account is added to the **Access policies** with all certificate permissions 3. Go to **Certificates**, select your CA certificate and click on **Delete** 4. After you have successful deleted the CA certificate you must click on **Manage deleted certificates** 5. Select your CA certificate, that you have deleted in Step 3 and click on **Purge** (Keep in mind that after you have purged the certificate you cannot restore it!) 6. Now restart your SCEPman App Services 7. Once your App Services are restarted open the SCEPman Dashboard by navigating to your SCEPman URL 8. You can see the section **Config issues**, please follow the steps in this section. 9. After you have generated the new CA certificate you can check the CA suitability in the SCEPman Dashboard. CA Suitability on SCEPman Dashboard: ![](/files/iGOE5BQIJRSLkmtDWgsV) ## Configuration Changes to the SCEPman Service To enable the feature, you must add two application settings in your SCEPman service. In the current implementation, we use a pre-shared key (password) for DC requests.\ **Please generate a new key/password and store it somewhere safe.** (you will need it in the following steps and later, on the domain Controllers) 1. Navigate to **App Services** 2. Then choose your SCEPman app 3. Next under **Settings** click **Environment variables** 4. Select Add 5. Type **AppConfig:DCValidation:Enabled** as Name (use \_\_ instead of : for Linux-based SCEPman) 6. Type **true** as Value 7. Confirm with **OK** 8. Select **Add** again 9. Type **AppConfig:DCValidation:RequestPassword** as Name (use \_\_ instead of : for Linux-based SCEPman) 10. Type your **key/password**, that you have generated earlier, as Value 11. Confirm with **OK** 12. Save the application settings ## Trust the CA certificate in the Domain for Kerberos Authentication Certificates used for Kerberos authentication need to be trusted within the AD domain as authentication CA certificates. Please download the CA certificate from the SCEPman Dashboard. If you stored the file as `scepman-root.cer`, you can publish the SCEPman CA certificate (be it a Root CA or an Intermediate CA) with the following command with an account that has Enterprise Administrator rights: ``` certutil -f -dsPublish scepman-root.cer NTAuthCA ``` Analogously, execute the following command to push the Root CA certificate (i.e. the SCEPman CA certificate or in case SCEPman is an Intermediate CA, the Root CA for the SCEPman CA certificate chain) to the Trusted Root certificate store for all machines in the AD Forest: ``` certutil -f -dsPublish scepman-root.cer RootCA ``` Afterwards, the CA certificate is generally trusted in AD and especially trusted for Kerberos Authentication. However, it takes some time (in default configuration up to 8 hours) until all devices receive this configuration. You may speedup this process on any machine by executing `gpupdate /force`, e.g. on the domain controllers. This ensures that the DC certificates are trusted within the domain. They are also trusted on all Intune-managed devices in the scope of a Trusted Certificate profile distributing the Root CA certificate. It can be necessary to distribute the Root CA manually to other services like appliances or cloud services to make the DC certificates trusted for all systems. ## Installation on the Client Then you must download our Open Source SCEP client software [SCEPClient](https://github.com/scepman/scepclient/releases). Releases with the suffix *-framework* use .NET Framework 4.6.2, which is pre-installed on Windows Server 2016 and compatible with newer versions. Other releases require the .NET Core Runtime to be installed on the target systems. Execute the following command in an elevated command prompt on a domain controller to receive a Domain Controller certificate from SCEPman: ``` ScepClient.exe newdccert https://your-scepman-domain/dc RequestPassword ``` You must add the SCEPman URL in the previous command but keep the path `/dc`. Replace `RequestPassword` with the secure key/password you generated earlier. The request password is encrypted with SCEPman's CA certificate, so only SCEPman can read it. Domain Controller certificates are only issued with the correct request password. ### Automated Certificate Renewal {% hint style="warning" %} The above command requests a new DC certificate whether or not there already is a valid certificate. See the following Section to learn how to renew certificates only if the existing certificate is about to expire. {% endhint %} For a fully automated renewal of certificates, you should distribute ScepClient to **all** your domain controllers, together with the PowerShell script [enroll-dc-certificate.ps1](https://github.com/scepman/scepclient/blob/Core31/enroll-dc-certificate.ps1). Add a Scheduled task that executes the following command in a SYSTEM context (adapt the URL and request password): ``` powershell -ExecutionPolicy RemoteSigned -File c:\scepman\enroll-dc-certificate.ps1 -SCEPURL https://your-scepman-domain/dc -SCEPChallenge RequestPassword -LogToFile ``` Please make sure that the PowerShell script resides in the same directory as SCEPClient.exe and its additional dependencies. ![Configuring the execution action in the Scheduled Task](/files/-MZWRYY9qUO42zgE1bWS) This checks for existing DC certificates in the machine store. Only if there are no suitable certificates with at least 30 days validity, it uses ScepClient.exe to request a new DC certificate from SCEPman. If you want to modify the 30-day-threshold, use the -ValidityThresholdDays parameter of the PowerShell script. The script writes a continuous log file to the directory where it is stored. If you do not want this log file, leave out the `-LogToFile` parameter. You can instead redirect the Information, Error, and/or Debug streams into files (e.g. `6>logfile.txt 2>&1`). For WHfB, all DCs running version 2016 or newer need a Kerberos Authentication certificate. Older DCs forward authentication requests to newer DCs, thus they do not necessarily require a Kerberos Authentication certificate. It is a best practice, though, to supply them with certificates, too. ### Phase-out of an Existing Internal PKI Please ensure that Internal PKIs do not enroll DC certificates (Certificate Templates "Domain Controller", "Domain Controller Authentication", and "Kerberos Authentication") in parallel with SCEPman. Otherwise, the DCs might use the DC certificate from the Internal PKI, which is considered untrusted if e.g. the CDP is unreachable. The SCEPman DC certificate can be used for all purposes for which the certificates of the above-mentioned templates can be used for, e.g. Kerberos authentication and LDAPS. The easiest way to accomplish this, is to stop the internal CAs issuing certificates for the templates "Domain Controller", "Domain Controller Authentication", and "Kerberos Authentication". In the Certification Authority MMC Snap-In, delete these templates from the list of issued templates of each Internal CA. Then, delete already issued certificates from the Internal CA from your Domain Controllers' "MY" Stores (`certlm.msc` and navigate to Personal). Even after a `gpupdate /force`, no new DC certificate from the Internal PKI should appear in the DC's Personal store. # Enrollment REST API {% hint style="warning" %} SCEPman Enterprise Edition only {% endhint %} SCEPman features a REST API to enroll certificates using the *Enrollment over Secure Transport* (EST) protocol. This is an alternative to the SCEP endpoints that require the SCEP-style of authentication, while the REST API uses Microsoft Identities for authentication. The protocol is also much simpler than SCEP. The REST API features two different authentication models. ### Self Service Enrollment As a user, you can interactively authenticate if you have the CSR.SelfService role. This allows you to request certificates for yourself and your devices. See [Self Service Enrollment](/certificate-management/api-certificates/self-service-enrollment) for more details. ### API Enrollment You can also authenticate as a service principal that has the CSR.Request.Db role. This allows you to automate certificate enrollment to servers, IoT devices, or in other use cases. See [API Enrollment](/certificate-management/api-certificates/api-enrollment) for details. # Self Service Enrollment {% hint style="info" %} Applicable to SCEPman version 2.9 and above {% endhint %} For clients to enroll certificates for themselves without SCEP, they can use the SCEPman REST API. However, they should not be able to enroll any arbitrary certificate, only certificates that are tied to their own identity. Therefore, the SCEPman API has a role that can be assigned to users/groups to enable this. ## Prerequisites * This role is included from SCEPman 2.9 onwards. If you installed SCEPman prior to this, you need to run the [installation script](/scepman-deployment/permissions/post-installation-config#running-the-scepman-installation-cmdlet) again for this role to appear. ## Assigning Self Service Permissions You can check that the Self Service role exists in the SCEPman-api App Registration:
You can create role assignments for users and groups in the SCEPman-api Enterprise Application.
## Certificate Enrollment Requests A user with the self-service role can only enroll certificates with the following attributes. (These are the same as the attributes you would select when enrolling certificates via a SCEP profile in [Intune ](/certificate-management/microsoft-intune)for instance). The certificate's validity will be tied to the device object in Intune or Entra Id or to the user object in Entra Id, analogously to Intune-enrolled certificates. {% hint style="info" %} If you are using the pre-supplied enrollment script from our [Section Use Cases](/use-cases), it will automatically generate a request according to these requirements. {% endhint %} ### Device Certificates Either the Subject Alternative Name (SAN) must include `IntuneDeviceID://` as an URI, where `` without the curly braces is the Device Id of the device in Intune. Or the CN field of the Subject must be the Entra ID device ID or the Intune Device Id.
FieldValue
SubjectCN=<AAD_Device_Id> or CN=<DeviceId>, where the device is one owned by the user.
SAN (URI)IntuneDeviceId://<IntuneDeviceId>
Basic ConstraintsSubject Type=End Entity
EKUsClient Authentication, 1.3.6.1.5.5.7.3.2
### User Certificates
FieldValue
SubjectCN=<DisplayName>
SAN (Other Name/UPN)<UserPrincipalName>
Basic ConstraintsSubject Type=End Entity
EKUsClient Authentication, 1.3.6.1.5.5.7.3.2
# Intune Managed Linux Client {% hint style="info" %} Applicable to SCEPman version 2.9 and above {% endhint %} {% hint style="warning" %} SCEPman Enterprise Edition only {% endhint %} This method can be used to enroll certificates for users and devices that are managed by Intune. Intune will in this case push a script to leverage the SCEPman REST API that in turn will either enroll a new certificate or renew an already existing one. Our developer Christoph presented this feature and some background details at the Workplace Ninja Usergroup Germany: {% embed url="" %} ## Prerequisites ### 1. Self Service Enrollment To enroll certificates, users must be authenticated to verify their eligibility. Follow this guide for step-by-step instructions on how to set this up {% content-ref url="/pages/BXprOF8vqXOL9Ro9F2J1" %} [Self Service Enrollment](/certificate-management/api-certificates/self-service-enrollment) {% endcontent-ref %} ### 2. App Service Settings #### Configuration *Required for certificate renewal* Configure your SCEPman App Service to accept mTLS client certificates. In the Configuration blade of the Settings section, verify that the Client certificate mode in Incoming client certificates is set to ***Optional Interactive User***.
Do not set the Client certificate mode to Require or Allow, as that would break normal operation of SCEPman on the SCEP endpoints! #### Environment Variables In order to make use of this scenario, you must set the following Environment Variables on the SCEPman app service. #### [AppConfig:DbCSRValidation:Enabled](https://docs.scepman.com/advanced-configuration/application-settings/dbcsr-validation#appconfig-dbcsrvalidation-enabled) *Required for certificate enrollment and renewal* Set this variable to ***true*** to enable the validation of certificate signing requests (CSRs). #### [AppConfig:DbCSRValidation:AllowRenewals](https://docs.scepman.com/advanced-configuration/application-settings/dbcsr-validation#appconfig-dbcsrvalidation-allowrenewals) *Required for certificate renewal* Set this variable to ***true*** to enable certificate renewals. #### [AppConfig:DbCSRValidation:ReenrollmentAllowedCertificateTypes](https://docs.scepman.com/advanced-configuration/application-settings/dbcsr-validation#appconfig-dbcsrvalidation-reenrollmentallowedcertificatetypes) *Required for certificate renewal* Set this variable to a comma separated list of certificate types that you want to allow the renewal. See the linked variable documentation for a list of possible certificate types. Example: ***Static,IntuneUser,IntuneDevice*** This scenario will enroll certificates of the type ***IntuneUser*** and ***IntuneDevice*** depending on your choice. ### **3. Client Prerequisites** The following prerequisites must be present on the executing client/host to be able to use the Enrollment REST API. #### [**Azure CLI**](https://learn.microsoft.com/en-us/cli/azure/install-azure-cli) **( version 2.61 and above)** The Azure CLI is used to authenticate the enrolling user to check their eligibility and to retrieve the access token. #### cURL Used to send the created CSR to the SCEPman Enrollment API Endpoint and receive certificate. #### OpenSSL OpenSSL is used to generate a private key and create a CSR for enrolling or renewing a certificate. #### [**Intune Enrollment**](https://learn.microsoft.com/en-us/mem/intune/user-help/enroll-device-linux) Follow the linked documentation to enroll your Linux client to Intune. ## Enrollment and Renewal Script The [enrollrenewcertificate.sh](https://github.com/scepman/csr-request/blob/main/enroll-certificate/enrollrenewcertificate.sh) script will be used to initially receive a certificate as well as checking it on a regular schedule and attempt a renewal in case the threshold is reached. While the script is usually operated by passing the parameters in the terminal we will need to modify some parts of it to be deployed over Intune. Locate the part of the script that assigns the passed terminal arguments to the variable and adjust them to your needs: Example configuration: ```bash APPSERVICE_URL="https://scepman.contoso.net/" API_SCOPE="api://b7d17d51-8b6d-45eb-b42b-3dae638cd5bc/Cert.Enroll" CERT_DIR=~/certs CERT_NAME="myCertificate" KEY_NAME="myKey" RENEWAL_THRESHOLD_DAYS=30 # Additionally add the following variables CERT_TYPE="user" CERT_COMMAND="auto" ``` #### APPSERVICE\_URL The URL of the SCEPman app service. *Example: ""* #### API\_SCOPE This is the API scope you can create in the ***SCEPman-api*** app registration in your environment. The user will be presented with your desired consent dialog and can afterwards user the self service functionality. *Example: "api://*b7d17d51-8b6d-45eb-b42b-3dae638cd5bc/Cert.Enroll*"*
#### CERT\_DIR The directory the certificate will be created or tried to be renewed. The private key and root certificate will also be placed in here. *Example: \~/certs/* #### CERT\_NAME The filename (without extension) of the certificate that will be created or read for renewal. *Example: "myCertificate"* #### KEY\_NAME The filename of the private key that will be created or read for renewal. *Example: "myKey"* #### RENEWAL\_THRESHOLD\_DAYS The amount of days the certificate will need to expire in for the script to begin the renewal process. *Example: 30* #### CERT\_TYPE The type of certificate that will be enrolled. *Can be either "user" or "device"* #### CERT\_COMMAND This defines the behavior of the script in relation to enrollment and renewal: **"auto"** will create a certificate initially or renew a certificate if it already exists and is about to expire. **"renewal"** will renew a certificate if it is about to expire but will not create a certificate initially. **"initial"** will only enroll a certificate but not renew a existing one. {% hint style="warning" %} If you are enrolling or renewing a device certificate the DeviceId will be retrieved from *\~/.config/intune/registration.toml* and the authenticated user will need to match the owner of the object in the configured [DeviceDirectory](https://docs.scepman.com/advanced-configuration/application-settings/intune-validation#appconfig-intunevalidation-devicedirectory). {% endhint %} ### Considerations * This script does not encrypt the generated keys (this requires passphrase input, so encryption has been omitted to allow for automatic renewal.) * If you are renewing passphrase-protected certificates from Certificate Master, you will need to input this passphrase in order to renew them. ## Deploy Script Using Intune we can deploy the modified script on a schedule to initially enroll a certificate with the given parameters and regularly check if it needs to be renewed. Add a new Linux script deployment and make sure to set the ***Execution context*** to ***User*** and either upload or paste the content of the modified bash script you created in the prior section. Adjust the ***Execution frequency*** in accordance to your renewal threshold. {% hint style="info" %} The user will be prompted to login to the Azure CLI application on the first execution as they are required to authenticate. {% endhint %} # Unmanaged Linux Client {% hint style="info" %} Applicable to SCEPman version 2.9 and above {% endhint %} {% hint style="warning" %} SCEPman Enterprise Edition only {% endhint %} This method can be used to enroll certificates for users and devices that are unmanaged or managed by an MDM other than Intune. ## Prerequisites ### 1. Self Service Enrollment To enroll certificates, users must be authenticated to verify their eligibility. Follow this guide for step-by-step instructions on how to set this up {% content-ref url="/pages/BXprOF8vqXOL9Ro9F2J1" %} [Self Service Enrollment](/certificate-management/api-certificates/self-service-enrollment) {% endcontent-ref %} ### 2. App Service Settings #### Configuration *Required for certificate renewal* Configure your SCEPman App Service to accept mTLS client certificates. In the Configuration blade of the Settings section, verify that the Client certificate mode in Incoming client certificates is set to ***Optional Interactive User***.
Do not set the Client certificate mode to Require or Allow, as that would break normal operation of SCEPman on the SCEP endpoints! #### Environment Variables In order to make use of this scenario, you must set the following Environment Variables on the SCEPman app service. #### [AppConfig:DbCSRValidation:Enabled](https://docs.scepman.com/advanced-configuration/application-settings/dbcsr-validation#appconfig-dbcsrvalidation-enabled) *Required for certificate enrollment and renewal* Set this variable to ***true*** to enable the validation of certificate signing requests (CSRs). #### [AppConfig:DbCSRValidation:AllowRenewals](https://docs.scepman.com/advanced-configuration/application-settings/dbcsr-validation#appconfig-dbcsrvalidation-allowrenewals) *Required for certificate renewal* Set this variable to ***true*** to enable certificate renewals. #### [AppConfig:DbCSRValidation:ReenrollmentAllowedCertificateTypes](https://docs.scepman.com/advanced-configuration/application-settings/dbcsr-validation#appconfig-dbcsrvalidation-reenrollmentallowedcertificatetypes) *Required for certificate renewal* Set this variable to a comma separated list of certificate types that you want to allow the renewal. See the linked variable documentation for a list of possible certificate types. Example: ***Static,IntuneUser,IntuneDevice*** This scenario will enroll certificates of the type ***IntuneUser.*** ## Powershell Module SCEPmanClient ### Initial Requests You can use the SCEPmanClient PowerShell module to request certificates on your Linux device: ```powershell New-SCEPmanCertificate -Url 'scepman.contoso.com' -SubjectFromUserContext -SaveToFolder '~/certs/' ``` The user will then need to interactively login in a browser session and a certificate for their logged in account will be created. ### Certificate Renewal You can also use the PowerShell module to renew already existing certificates. This will also spare the requirement to use a service principal for authentication: ```powershell $Parameters = @{ 'CertificateFromFile' = '~/certs/john.doe@contoso.com.pem' 'KeyFromFile' = '~/certs/john.doe@contoso.com.key' 'SaveToFolder' = '~/certs/' } New-SCEPmanCertificate @Parameters ``` ## Enrollment and Renewal Script If the PowerShell module is not an option for you, the [enrollrenewcertificate.sh](https://github.com/scepman/csr-request/blob/main/enroll-certificate/enrollrenewcertificate.sh) script can be used to initially receive a certificate as well as to verify it and attempt a renewal in case it is about to expire. ### **Client Prerequisites** The following prerequisites must be present on the executing client/host to be able to use the Enrollment REST API. #### [**Azure CLI**](https://learn.microsoft.com/en-us/cli/azure/install-azure-cli) **( version 2.61 and above)** The Azure CLI is used to authenticate the enrolling user to check their eligibility and to retrieve the access token. #### cURL Used to send the created CSR to the SCEPman Enrollment API Endpoint and receive certificate. #### OpenSSL OpenSSL is used to generate a private key and create a CSR for enrolling or renewing a certificate. Example: {% code overflow="wrap" %} ```bash ./enrollrenewcertificate.sh -u https://scepman.contoso.net/ api://b7d17d51-8b6d-45eb-b42b-3dae638cd5bc/Cert.Enroll ~/certs/ "myCertificate" "myKey" 30 ``` {% endcode %} #### 1. Command Defines the behavior of the script Can be any of: **-u** for user certificate with auto-detection whether it is an initial enrollment or renewal **-d** for device certificate with auto-detection whether it is an initial enrollment or renewal **-r** for renewal **-w** for initial enrollment of a user **-x** for initial enrollment of a device {% hint style="warning" %} If you are enrolling or renewing a device certificate the DeviceId will be tried to read from *\~/.config/intune/registration.toml* by default and the authenticated user will need to match the owner of the object in the configured [DeviceDirectory](https://docs.scepman.com/advanced-configuration/application-settings/intune-validation#appconfig-intunevalidation-devicedirectory) {% endhint %} #### 2. App Service URL The URL of the SCEPman app service. *Example: ""* #### 3. API\_SCOPE This is the API scope you can create in the ***SCEPman-api*** app registration in your environment. The user will be presented with your desired consent dialog and can afterwards user the self service functionality. *Example: "api://*b7d17d51-8b6d-45eb-b42b-3dae638cd5bc/Cert.Enroll*"*
#### 4. Certificate Directory The directory the certificate will be created or tried to be renewed. *Example: \~/certs/* #### 5. Certificate Filename The filename (without extension) of the certificate that will be created or read for renewal. *Example: "myCertificate"* #### 6. Private Key Filename The filename of the private key that will be created or read for renewal. *Example: "myKey"* #### 7. Renewal Threshold The amount of days the certificate will need to expire in for the script to begin the renewal process. *Example: 30* ### Considerations * This script does not encrypt the generated keys (this requires passphrase input, so encryption has been omitted to allow for automatic renewal.) * If you are renewing passphrase-protected certificates from Certificate Master, you will need to input this passphrase in order to renew them. ## Set up automatic renewal When the above bash script is run and detects that a certificate has already been enrolled, it will renew the certificate (if it is close to expiry) using mTLS. If the script is run regularly, this will ensure the certificate is renewed when it gets close to expiry. You can set up a cronjob to achieve this. The below command is an example of how this could be done. It will set up a cronjob to run the command daily (if the system is powered on) and a cronjob to run the command on reboot. 
(crontab -l ; echo @daily /path/to/enrollrenewcertificate.sh -u https://scepman.contoso.net/ api://b7d17d51-8b6d-45eb-b42b-3dae638cd5bc/Cert.Enroll /home/user/certs/ "myCertificate" "myKeyName" 30 ; echo @reboot /path/to/enrollrenewcertificate.sh -u https://scepman.contoso.net/ api://b7d17d51-8b6d-45eb-b42b-3dae638cd5bc/Cert.Enroll /home/user/certs/ "myCertificate" "myKeyName" 30 ) | crontab -
Since commands run by Cron will not necessarily be run from the directory that the script/certificates are in, it is important to provide the absolute paths to the script/certificates. # API Enrollment Use this REST API using Microsoft Identities for authentication to enroll certificates as an alternative to the SCEP endpoints that require the SCEP-style of authentication. {% hint style="info" %} This feature requires version **2.3.689** or above. {% endhint %} {% hint style="warning" %} SCEPman Enterprise Edition only {% endhint %} SCEPman features a REST API to enroll certificates. This is an alternative to the SCEP endpoints that require the SCEP-style of authentication, while the REST API uses Microsoft Identities for authentication. The protocol is also much simpler than SCEP. ## Prerequisites ### 1. Service Principal {% stepper %} {% step %} ### App Registration Create a new *App Registration* that describes your use case. You application will authenticate as this application against SCEPman. {% endstep %} {% step %} ### API Permissions #### CSR.Request.Db Assign the required permissions by running the **Register-SCEPmanApiClient** cmdlet from the SCEPman PowerShell module. Example: ```powershell Register-SCEPmanApiClient -ServicePrincipalId xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx ``` *ServicePrincipalId* The ***Object ID*** of the complementing ***Enterprise Application*** of the App Registration we created in the previous step. Note that this does not refer to the Enterprise Application usually named SCEPman-api, which identifies SCEPman itself. To manually assign this permission you can navigate to *API Permissions* and add a permission from the *permissions your organization uses*. Assign the ***CSR.Request.Db*** permission from ***SCEPman-api*** as an *application permission*. #### Application.Read.All (Optional) *Service Principals* will also require the Graph permission ***Application.Read.All*** to allow automatic retrieval of SCEPman's API scope for authentication. The permission can be added manually like so:
{% endstep %} {% step %} ### Client Secret Create a client secret under "Certificates & Secrets." The Client Secret will be used as a password to authenticate the application later. {% endstep %} {% endstepper %} ### 2. App Service Settings #### Configuration *Required for certificate renewal* Configure your SCEPman App Service to accept mTLS client certificates. In the Configuration blade of the Settings section, verify that the Client certificate mode in Incoming client certificates is set to ***Optional Interactive User***.
Do not set the Client certificate mode to Require or Allow, as that would break normal operation of SCEPman on the SCEP endpoints! #### Environment Variables In order to make use of this scenario, you must set the following Environment Variables on the SCEPman app service. #### [AppConfig:DbCSRValidation:Enabled](https://docs.scepman.com/advanced-configuration/application-settings/dbcsr-validation#appconfig-dbcsrvalidation-enabled) *Required for certificate enrollment and renewal* Set this variable to ***true*** to enable the validation of certificate signing requests (CSRs). #### [AppConfig:DbCSRValidation:AllowRenewals](https://docs.scepman.com/advanced-configuration/application-settings/dbcsr-validation#appconfig-dbcsrvalidation-allowrenewals) *Required for certificate renewal* Set this variable to ***true*** to enable certificate renewals. #### [AppConfig:DbCSRValidation:ReenrollmentAllowedCertificateTypes](https://docs.scepman.com/advanced-configuration/application-settings/dbcsr-validation#appconfig-dbcsrvalidation-reenrollmentallowedcertificatetypes) *Required for certificate renewal* Set this variable to a comma separated list of certificate types that you want to allow the renewal. See the linked variable documentation for a list of possible certificate types. Example: ***Static,IntuneUser,IntuneDevice*** ## Enrolling certificates After you have prepared the prerequisites, you can POST a PKCS#10/CMS to your SCEPman with the HTTP path *api/csr*. The HTTP Response will be the freshly issued certificate in DER encoding. SCEPman will store all issued certificates automatically in its Storage Account, so you can conveniently list and revoke them via the Certificate Master component. A convenient method to send those request is our SCEPmanClient PowerShell module: {% content-ref url="/pages/k0e2z2MUtrOMOkgS5ZKy" %} [SCEPmanClient](/certificate-management/api-certificates/scepmanclient) {% endcontent-ref %} ## Other Examples See our [Open Source Sample Library on GitHub](https://github.com/scepman/csr-request) to find out how to use SCEPman's REST API. # Linux Server {% hint style="info" %} This feature requires version **2.3.689** or above. {% endhint %} {% hint style="warning" %} SCEPman Enterprise Edition only {% endhint %} While the other of SCEPmans use cases provide the ability to interactively authenticate a user to then only allow them to enroll user certificates for their account or their devices you might want to be able to non-interactively enroll certificates for arbitrary subjects. To accomplish this we can authenticate a service principal and allow that to leverage SCEPman's Enrollment REST API. ## Prerequisites Please refer to the API Enrollment article on how to create a service principal that can be used for authentication: {% content-ref url="/pages/0hD3y9R5SjzwVGxe3Vdj" %} [API Enrollment](/certificate-management/api-certificates/api-enrollment) {% endcontent-ref %} ## Powershell Module SCEPmanClient ### Initial Requests You can use the SCEPmanClient PowerShell module to request certificates on your Linux server: ```powershell $Parameters = @{ 'Url' = 'scepman.contoso.com' 'ClientId' = '569fbf51-aa63-4b5c-8b26-ebbcfcde2715' 'TenantId' = '8aa3123d-e76c-42e2-ba3c-190cabbec531' 'ClientSecret' = 'csa8Q~aVaWCLZTzswIBGvhxUiEvhptuqEyJugb70' 'Subject' = 'CN=LinuxServer' 'IP' = '10.22.11.8' 'ExtendedKeyUsage' = 'ServerAuth' 'SaveToFolder' = '/etc/ssl/scepman' 'IncludeRootCA' = $true } New-SCEPmanCertificate @Parameters ``` ### Certificate Renewal You can also use the PowerShell module to renew already existing certificates. This will also spare the requirement to use a service principal for authentication: ```powershell $Parameters = @{ 'CertificateFromFile' = '/home/user/.certs/server.pem' 'KeyFromFile' = '/home/user/.certs/server.key' 'SaveToFolder' = '/home/user/.certs' } New-SCEPmanCertificate @Parameters ``` ## Enrollment and Renewal Script If the PowerShell module is not an option for you, the [enrollrenewcertificate.sh](https://github.com/scepman/csr-request/blob/main/enroll-certificate/enrollrenewcertificate.sh) script can be used to initially receive a certificate as well as to verify it and attempt a renewal in case it is about to expire. ### Client Prerequisites The following prerequisites must be present on the executing client/host to be able to use the Enrollment REST API. #### [**Azure CLI**](https://learn.microsoft.com/en-us/cli/azure/install-azure-cli) **( version 2.61 and above)** The Azure CLI is used to authenticate the enrolling user to check their eligibility and to retrieve the access token. #### cURL Used to send the created CSR to the SCEPman Enrollment API Endpoint and receive certificate. #### OpenSSL OpenSSL is used to generate a private key and create a CSR for enrolling or renewing a certificate. Example: {% code overflow="wrap" %} ```bash ./enrollrenewcertificate.sh -s https://scepman.contoso.net/ api://a7a1d6c8-51b9-48ec-9ca0-a363dc2c8436 ~/certs/ "myCertificate" "myKeyName" 30 edbc406b-7384-414e-af8b-1a3b187b3f7e [Client_Secret] 736e80bb-3102-479b-83ba-e45c80ef723b "/CN=SubjectName,O=Organization" "DNS:webserver.contoso.com" ``` {% endcode %} #### 1. Command Defines the behavior of the script For this use case we can use the following options: **-s** for server certificate with auto-detection whether it is an initial enrollment or renewal **-y** for initial enrollment of a server certificate **-c** for submitting a present certificate signing request For Client Authentication use cases see: {% content-ref url="/pages/hXCFiZOOB7jyxHMWH572" %} [Unmanaged Linux Client](/certificate-management/api-certificates/self-service-enrollment/unmanaged-linux-client) {% endcontent-ref %} #### 2. App Service URL The URL of the SCEPman app service. *Example: ""* #### 3. API Scope This is the ***Application ID URI*** of the ***SCEPman-api*** app registration in your environment. *Example: "api://a7a1d6c8-51b9-48ec-9ca0-a363dc2c8436"*
#### 4. Certificate Filename The filename (without extension) of the certificate that will be created or read for renewal. *Example: "myCertificate"* #### 5. Certificate Directory The directory the certificate will be created or tried to be renewed. *Example: \~/certs/* #### 8. Renewal Threshold The amount of days the certificate will need to expire in for the script to begin the renewal process. *Example: 30* ### *Additional parameters for Server Certificates:* #### 9. Service Principal Client Id The Application (Client) Id of the app registration we want to authenticate. #### 10. Service Principal Client Secret The created client secret of the app registration we want to authenticate. #### 11. Service Principal Tenant Id The tenant id of our app registration. #### 12. Certificate Subject The subject you want to enroll the certificate with. *Format: /CN=SubjectName,O=Organization* #### 13. Certificate Extension This will be added as subject alternative name *Example: DNS:webserver.contoso.com* ### *Usage example for CSR signing (-c command)* {% code overflow="wrap" %} ```bash # Generate a private key openssl genrsa -out myKey.rsa 4096 # Create a csr for a user certificate for client authentication openssl req -new -key myKey.rsa -sha256 -out myCSR -subj "/CN=John Smith" -addext "subjectAltName=otherName:1.3.6.1.4.1.311.20.2.3;UTF8:john.smith@contoso.net" -addext "extendedKeyUsage=1.3.6.1.5.5.7.3.2" ./enrollrenewcertificate.sh -c https://scepman.contoso.net/ api://a7a1d6c8-51b9-48ec-9ca0-a363dc2c8436 ~/certs "myCertificate" myKey.rsa 30 edbc406b-7384-414e-af8b-1a3b187b3f7e [Client_Secret] 736e80bb-3102-479b-83ba-e45c80ef723b myCSR ``` {% endcode %} #### Considerations * This script does not encrypt the generated keys (this requires passphrase input, so encryption has been omitted to allow for automatic renewal.) * If you are renewing passphrase-protected certificates from Certificate Master, you will need to input this passphrase in order to renew them. ## Set up automatic renewal When the above bash script is run and detects that a certificate has already been enrolled, it will renew the certificate (if it is close to expiry) using mTLS. If the script is run regularly, this will ensure the certificate is renewed when it gets close to expiry. You can set up a cronjob to achieve this. The below command is an example of how this could be done. It will set up a cronjob to run the command daily (if the system is powered on) and a cronjob to run the command on reboot. {% code overflow="wrap" %} ``` (crontab -l ; echo @daily /path/to/enrollrenewcertificate.sh -s https://scepman.contoso.net/ api://a7a1d6c8-51b9-48ec-9ca0-a363dc2c8436 /path/to/certs "myCertificate" "myKeyName" 30 edbc406b-7384-414e-af8b-1a3b187b3f7e [Client_Secret] 736e80bb-3102-479b-83ba-e45c80ef723b "/CN=SubjectName,O=Organization" "DNS:webserver.contoso.com" ; echo @reboot /path/to/enrollrenewcertificate.sh -s https://scepman.contoso.net/ api://a7a1d6c8-51b9-48ec-9ca0-a363dc2c8436 /path/to/certs "myCertificate" "myKeyName" 30 edbc406b-7384-414e-af8b-1a3b187b3f7e [Client_Secret] 736e80bb-3102-479b-83ba-e45c80ef723b "/CN=SubjectName,O=Organization" "DNS:webserver.contoso.com") | crontab - ``` {% endcode %} Since commands run by Cron will not necessarily be run from the directory that the script/certificates are in, it is important to provide the absolute paths to the script/certificates. # Windows Server {% hint style="info" %} Applicable to SCEPman version 2.9 and above {% endhint %} You can use the SCEPmanClient PowerShell module to request certificates for your Windows server. Please refer to the main article of the module for the prerequisites: {% content-ref url="/pages/k0e2z2MUtrOMOkgS5ZKy" %} [SCEPmanClient](/certificate-management/api-certificates/scepmanclient) {% endcontent-ref %} ## Use Case Description While the module is capable of initially requesting certificates, it might not be desirable to store the service principal credentials on a machine that could be used to request arbitrary certificates. So if your scenario includes the deployment of a certificate using Certificate Master you can automatically renew it using *SCEPmanClient* by providing an already existing certificate for authentication: 
$Subject = $env:COMPUTERNAME
$ValidityThreshold = 30

$CertificateToRenew = Get-ChildItem Cert:\LocalMachine\My `
                        | Where-Object NotAfter -lt (Get-Date).AddDays($ValidityThreshold) `
                        | Where-Object Subject -match $Subject

New-SCEPmanCertificate -Certificate $CertificateToRenew -SaveToStore 'LocalMachine'

# With the new certificate in place we can remove the old one
# Remove-Item $CertificateToRenew.PSPath
This example will find certificates expiring in the next month and use it to authenticate the renewal request. ## Initial Request If you want to request certificates on your server initially you can do so by supplying a service principal for authentication that has the role **CSR DB Requesters** assigned. Please refer to the following guide on how to implement such a service principal: {% content-ref url="/pages/0hD3y9R5SjzwVGxe3Vdj" %} [API Enrollment](/certificate-management/api-certificates/api-enrollment) {% endcontent-ref %} ```powershell $Parameters = @{ 'Url' = 'scepman.contoso.com' 'ClientId' = '569fbf51-aa63-4b5c-8b26-ebbcfcde2715' 'TenantId' = '8aa3123d-e76c-42e2-ba3c-190cabbec531' 'ClientSecret' = 'csa8Q~aVaWCLZTzswIBGvhxUiEvhptuqEyJugb70' 'Subject' = 'CN=WebServer' 'DNSName' = 'Webserver.domain.local' 'ExtendedKeyUsage' = 'ServerAuth' 'SaveToStore' = 'LocalMachine' } New-SCEPmanCertificate @Parameters ``` If we now want to renew a certificate we can disregard the service principal and use an already issued certificate for authentication. This will use the existing certificates details to construct a new CSR and issue it to SCEPman for a new certificate. # SCEPmanClient SCEPmanClient is a PowerShell module intended to interact with SCEPmans REST API. Being platform independent and compatible with Windows PowerShell v5, you can use this module to request certificates for all use cases the REST API can be used for: * Automatic issuance of server certificates * Client certificates for unmanaged devices * Enrollment of certificates to Linux devices ## Installation The SCEPmanClient module is available from the PowerShell Gallery and can be installed using the following command: ```powershell Install-Module -Name SCEPmanClient ``` {% hint style="info" %} Follow Microsoft's guide on how to install PowerShell on [Linux](https://learn.microsoft.com/en-us/powershell/scripting/install/installing-powershell-on-linux?view=powershell-7.5) or [MacOS](https://learn.microsoft.com/en-us/powershell/scripting/install/installing-powershell-on-macos?view=powershell-7.5). {% endhint %} ## Prerequisites For the module to be functioning as expected you will need to add a small modification to your SCEPman deployment: {% stepper %} {% step %} ### Add Home page URL Add SCEPman's App Service URL: Navigate to the `Branding & Properties` section of the app registration. Add SCEPman's App Service URL to the Home page URL field:
This is required for the module to be able to automatically look up the App Registrations client id that is needed for access token retrieval. {% endstep %} {% step %} ### Allow Azure PowerShell to interact with the App Registration In the App Registration, navigate to *Expose an API* and create a custom scope that can be used to authorize the client Id `1950a258-227b-4e31-a9cf-717495945fc2` (Microsoft Azure PowerShell)

Example information for a custom API scope

After creating an API scope, the Azure PowerShell application can be authorized:

Authorized Microsoft Azure PowerShell application

{% endstep %} {% step %} ### Enable EST endpoint #### Configuration *Required for certificate renewal* Configure your SCEPman App Service to accept mTLS client certificates. In the Configuration blade of the Settings section, verify that the Client certificate mode in Incoming client certificates is set to ***Optional Interactive User***.
Do not set the Client certificate mode to Require or Allow, as that would break normal operation of SCEPman on the SCEP endpoints! #### Environment Variables In order to make use of this scenario, you must set the following Environment Variables on the SCEPman app service. #### [AppConfig:DbCSRValidation:Enabled](https://docs.scepman.com/advanced-configuration/application-settings/dbcsr-validation#appconfig-dbcsrvalidation-enabled) *Required for certificate enrollment and renewal* Set this variable to ***true*** to enable the validation of certificate signing requests (CSRs). #### [AppConfig:DbCSRValidation:AllowRenewals](https://docs.scepman.com/advanced-configuration/application-settings/dbcsr-validation#appconfig-dbcsrvalidation-allowrenewals) *Required for certificate renewal* Set this variable to ***true*** to enable certificate renewals. #### [AppConfig:DbCSRValidation:ReenrollmentAllowedCertificateTypes](https://docs.scepman.com/advanced-configuration/application-settings/dbcsr-validation#appconfig-dbcsrvalidation-reenrollmentallowedcertificatetypes) *Required for certificate renewal* Set this variable to a comma separated list of certificate types that you want to allow the renewal. See the linked variable documentation for a list of possible certificate types. Example: ***Static,IntuneUser,IntuneDevice*** {% endstep %} {% endstepper %} ## Permissions SCEPman has different roles that will allow different kinds of certificates to be enrolled. You can assign those in the *SCEPman-api* (default name) Enterprise Application: #### CSR DB Requesters This role is only assignable to service principals (App Registrations for example) by default and allows to request certificates with arbitrary subjects and usages. {% content-ref url="/pages/0hD3y9R5SjzwVGxe3Vdj" %} [API Enrollment](/certificate-management/api-certificates/api-enrollment) {% endcontent-ref %} #### CSR Self Service This role can be assigned to users and will allow certificates to be enrolled with the following restrictions: * Only ClientAuth EKU * User certificates need to match the users UPN in either the subject or UPN subject alternative name * Device certificates need to have a subject or SAN that SCEPman can map to a device object owned by the authenticated user {% content-ref url="/pages/BXprOF8vqXOL9Ro9F2J1" %} [Self Service Enrollment](/certificate-management/api-certificates/self-service-enrollment) {% endcontent-ref %} ## Usage Examples ### Use Azure Authentication #### Interactive Authentication When requesting a new certificate without specifying the authentication mechanism, the user will be authenticated interactively by default. By using the `-SubjectFromUserContext` parameter, the certificate's subject and UPN SAN will be automatically populated based on the logged-in user's context: ```powershell New-SCEPmanCertificate -Url 'scepman.contoso.com' -SubjectFromUserContext -SaveToStore CurrentUser ``` #### Device Login If you want to request a new certificate on a system without any desktop environment you can use the `-DeviceCode` parameter to perform the actual authentication on another session: ```powershell New-SCEPmanCertificate -Url 'scepman.contoso.com' -DeviceCode -SubjectFromUserContext -SaveToFolder /home/user/certificates ``` #### Service Principal Authentication In fully automated scenarios an App Registration can be used for authentication. Inferring the subject from the authenticated context will not be possible in this case. Parameter splatting will also make the execution more readable: ```powershell $Parameters = @{ 'Url' = 'scepman.contoso.com' 'ClientId' = '569fbf51-aa63-4b5c-8b26-ebbcfcde2715' 'TenantId' = '8aa3123d-e76c-42e2-ba3c-190cabbec531' 'ClientSecret' = 'csa8Q~aVaWCLZTzswIBGvhxUiEvhptuqEyJugb70' 'Subject' = 'CN=WebServer' 'DNSName' = 'Webserver.domain.local' 'ExtendedKeyUsage' = 'ServerAuth' 'SaveToStore' = 'LocalMachine' } New-SCEPmanCertificate @Parameters ``` ### Authenticate using certificates Once a certificate has been issued using an authenticated context we can use it to renew it without providing any context again. #### CertificateBySubject *Interacting with keystores is only possible on Windows* When providing the `CertificateBySubject` parameter, the module will automatically try find a suitable certificate for renewal in the *CurrentUser* and *LocalMachine* keystores. The entered value will be regex matched against the subjects in all available certificates. ```powershell New-SCEPmanCertificate -CertificateBySubject 'WebServer' -SaveToStore 'LocalMachine' ``` #### Provide a specific certificate ```powershell $Certificate = Get-ChildItem Cert:\LocalMachine\My | Where-Object Thumbprint -eq '9B08EA68B16773CEF3C49D5D95BE50B784638984' New-SCEPmanCertificate -Certificate $Certificate -SaveToStore LocalMachine ``` #### CertificateFromFile On Linux systems a certificate renewal can be performed by passing the paths of an existing certificate and its private key. ```powershell New-SCEPmanCertificate -CertificateFromFile '~/certs/myCert.pem' -KeyFromFile '~/certs/myKey.key' -SaveToFolder '~/certs' ``` When using an encrypted private key you will asked for the password. You can also directly pass the keys password using the `PlainTextPassword` parameter. #### Using SCEPman with a Azure Web Application Firewall With SSL Profiles enabled, the WAF will terminate the TLS connections. This will in turn break certificate renewals using EST as the procedure relies on mTLS for authentication. In this case the `UseSCEPRenewal` parameter can be used to instead perform a certificate renewal complying with the SCEP protocol. ```powershell New-SCEPmanCertificate -CertificateBySubject 'WebServer' -SaveToStore 'LocalMachine' -UseSCEPRenewal ``` Please note that this requires additional SCEPman configuration regarding the static SCEP endpoint: * AppConfig:StaticValidation:Enabled : true * AppConfig:StaticValidation:AllowRenewals : true * AppConfig:StaticValidation:ReenrollmentAllowedCertificateTypes: Static (Depending on the types intended for renewal) # Management REST API {% hint style="warning" %} SCEPman Enterprise Edition only Applicable to version 3.1 and above {% endhint %} The Management API provides administrative access to issued certificates in SCEPman. It is intended for management and operational workflows such as locating certificates and revoking them when needed. These endpoints are available under `/api/manage` and require an authenticated user with the **Manage.All** role in SCEPman-api. {% hint style="info" %} If you update from an earlier SCEPman version, you might not yet have the Manage.All role. Run `Complete-SCEPmanInstallation` again in a cloud shell to automatically add it to your SCEPman-api application. {% endhint %} ### Authentication The API uses Entra authentication. The easiest way to authenticate is often the Microsoft Authentication Library (MSAL). One way to get a bearer token for the Management API is with the Azure CLI. The required value for the \`--resource\` parameter is the Application ID URI of your SCEPman-api app registration (usually its Application ID prefixed with `api://`). ```bash az account get-access-token --resource api://[APPLICATION-ID] --query accessToken --output tsv ``` For example: ```bash TOKEN=$(az account get-access-token \ --resource api://16b6a4d1-0a20-4b41-bf58-12783034cad3 \ --query accessToken \ --output tsv) ``` You can then use that token in the API calls: ```bash curl -X GET "https://scepman.contoso.com/api/manage/search?searchText=ABC123&pageSize=10&certValidity=Any&certType=Any" \ -H "Authorization: Bearer $TOKEN" \ -H "Accept: application/json" ``` ### Search API **`GET /api/manage/search`** Searches issued certificates and returns a paginated result set. #### Search parameters **`searchText`** Free-text search term used to find matching certificates. This is typically used for substring-based lookups, for example matching requester or other searchable certificate metadata. **`pageSize`** Maximum number of certificates returned in a single response page. * Default: 50 **`continuationToken`** Optional pagination token used to request the next page of results.\ Pass back the `continuationToken` returned by a previous search response to continue fetching more certificates. **`certValidity`** Filters certificates by validity state. * Default: `Any` Valid values are `Any`, `Active`, `Expired`, `Revoked`. **`certType`** Filters certificates by certificate type. * Default: `Any` This can be used to restrict the result set to specific certificate categories. Valid values are `Static`, `DC`, `User`, `Device`, and `Any`. **`Sources`** Filters certificates by the endpoint through which they have been issued. You can specify this filter multiple times, once per source. * Default: No restriction Valid values are shown in the table below, you must specify the source using their integer values: | Source | Value | | ----------------- | --------------------------------------- | | CertificateMaster | 0 | | Intune | 1 or 9 (use both to ensure finding all) | | Static | 3 | | StaticAAD | 4 | | Jamf | 5 | | DomainController | 6 | | API | 7 | | RadiusAPI | 8 | | Active Directory | 10 | The response is a paginated list of certificate records plus a continuation token for fetching the next page. **Example** ```bash curl -X GET "https://scepman.contoso.com/api/manage/search?searchText=507AEAC03CCEF83F106914418D9222E466A629C1&pageSize=10&certValidity=Any&certType=Any" \ -H "Authorization: Bearer " \ -H "Accept: application/json" ``` **Example response** ```json { "items": [ { "serialNumber": "507AEAC03CCEF83F106914418D9222E466A629C1", "subject": "CN=device01.contoso.local", "sans": null, "upn": null, "issuanceDate": "2026-05-28T10:57:22Z", "expirationDate": "2028-05-28T10:57:22Z", "revocationDate": null, "revocationReason": null, "revokedBy": null, "requester": "pkiAdmin@contoso.com", "source": "CertificateMaster", "certificateType": "Static" } ], "continuationToken": "..." } ``` ### **Revocation API** **`PATCH /api/manage/revoke/{serialNumber}`** Revokes a certificate identified by its serial number. The request body contains: * `revocationReason` - an integer for the reason of revocation. See the table below for possible values * `revoker` *(optional)* - a free-text identifier for the person or system requesting revocation {% hint style="info" %} If specified, we recommend to use the UPN for the revoker field. If not specified, the logged on user's UPN will be used. Even if specified, the logged on user's UPN is still added in the form "{revoker} through API user ${logged on user}". This value is used for auditing and in searches. {% endhint %} **Example** ```bash curl -X PATCH "https://scepman.contoso.com/api/manage/revoke/ABC123" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "revocationReason": 4, "revoker": "pkiAdmin@contoso.com" }' ``` **Successful response** ```http HTTP/1.1 200 OK ``` **Certificate not found** ```http HTTP/1.1 404 Not Found Content-Type: application/json ``` ```json { "errorMessage": "Certificate not found.", "errorCode": 7012 } ``` **Already revoked** ```http HTTP/1.1 409 Conflict Content-Type: application/json ``` ```json { "errorMessage": "The certificate is already revoked.", "errorCode": 5013 } ``` #### Supported revocation reasons The API supports the revocation reasons specified in [RFC 5280](https://datatracker.ietf.org/doc/html/rfc5280#section-5.3.1): | Value | Revocation Reason | | ----- | -------------------- | | 0 | Unspecified | | 1 | KeyCompromise | | 2 | CACompromise | | 3 | AffiliationChanged | | 4 | Superseded | | 5 | CessationOfOperation | | 6 | CertificateHold | | 8 | RemoveFromCrl | | 9 | PrivilegeWithdrawn | | 10 | AACompromise | # Management API in SCEPmanClient Use `Find-SCEPmanCertificate` to search for issued certificates in SCEPman and `Revoke-SCEPmanCertificate` to revoke a certificate when it is no longer trusted or no longer needed. ### Requirements Before you can search for or revoke certificates, ensure that your identity has the **Manage.All** role. Also ensure to have setup the general prerequisites for SCEPmanClient usage: [https://app.gitbook.com/o/-LhPlvZ6dc8XcqY7tdZw/s/-LoGejQeUQcw7lqnQ3WX/\~/edit/\~/changes/863/certificate-management/api-certificates/scepmanclient#prerequisites](/certificate-management/api-certificates/scepmanclient#prerequisites) {% hint style="info" %} If you update from an earlier SCEPman version, you might not yet have the Manage.All role. Run `Complete-SCEPmanInstallation` again in a cloud shell to automatically add it to your SCEPman-api application. {% endhint %} ### Find certificates Use `Find-SCEPmanCertificate` to search for certificates by their serial number, subject or requester. If at least one certificate is found, an object is returned resembling the following JSON structure: ```json { "items": [ { "serialNumber": "507AEAC03CCEF83F106914418D9222E466A629C1", "subject": "CN=device01.contoso.local", "sans": null, "upn": null, "issuanceDate": "2026-05-28T10:57:22Z", "expirationDate": "2028-05-28T10:57:22Z", "revocationDate": null, "revocationReason": null, "revokedBy": null, "requester": "pkiAdmin@contoso.com", "source": "CertificateMaster", "certificateType": "Static" } ], "continuationToken": "..." } ``` #### Example: Find a single certificate by serial number ```powershell Find-SCEPmanCertificate -Url scepman.conitoso.com ` -SearchText '5056BB9B823132CB26210A4C90A62FB3C25E38D0' ` | Select-Object -ExpandProperty items serialNumber : 5056BB9B823132CB26210A4C90A62FB3C25E38D0 subject : CN=clara.oswald@contoso.com sans : clara.oswald@contoso.com upn : clara.oswald@contoso.com issuanceDate : 2026-05-28T11:06:11Z expirationDate : 2028-05-28T11:06:11Z revocationDate : revocationReason : revokedBy : requester : pkiAdmin@contoso.com source : CertificateMaster certificateType : Static ``` ### Understand paged results If the result set is large, `Find-SCEPmanCertificate` can return a continuation token. Use this token to request the next page. #### Example: first page with continuation token ```powershell $result = Find-SCEPmanCertificate -Url scepman.contoso.com -SearchText "CN=device" $result ``` Example output: ```powershell ContinuationToken : 1!48!ODY2OURBN0QtQzk0My00QjU3LUI5OEYtNzA5RjY5MDlCRDkw Items : {@{serialNumber=60B26DD32CF07F30D6760848A5233CBAE90DCDBC; subject=CN=device01.contoso.local}, @{serialNumber=50F1754E85238752527C3140ABD0CEF2C7DC9439; subject=CN=device02.contoso.local}} ``` #### Show returned certificates in detail ```powershell $result = Find-SCEPmanCertificate -Url scepman.contoso.com -SearchText "CN=device" $result.Items ``` Example output: ```powershell serialNumber subject ------------ ------- 60B26DD32CF07F30D6760848A5233CBAE90DCDBC CN=device01.contoso.local 50F1754E85238752527C3140ABD0CEF2C7DC9439 CN=device02.contoso.local ``` #### Request the next page with the continuation token ```powershell $firstPage = Find-SCEPmanCertificate -Url scepman.contoso.com -SearchText "CN=device" $nextPage = Find-SCEPmanCertificate -Url scepman.contoso.com -ContinuationToken $firstPage.ContinuationToken $nextPage.Items ``` Example output: ```powershell serialNumber subject ------------ ------- 5048D2541F7F401C42B7E943A7C82FB37A179F83 CN=device03.contoso.local 50BCCDA973AEEA55E00FAF4A9A088DFB7564F263 CN=device04.contoso.local ``` ### Revoke a certificate Use `Revoke-SCEPmanCertificate` to revoke a certificate by its serial number that was previously issued. ```powershell Revoke-SCEPmanCertificate -SerialNumber "480552CEBBE40FD5D4417532033728F353040000" -RevocationReason CessationOfOperation ``` #### Example: Find a certificate and revoke it ```powershell $result= Find-SCEPmanCertificate -Url scepman.contoso.com -SearchText "480552CEBBE40FD5D4417532033728F353040000" $cert = $result.items Revoke-SCEPmanCertificate -SerialNumber $cert.Items[0].serialNumber ``` Example output: ```powershell Revoke-SCEPmanCertificate: Certificate 480552CEBBE40FD5D4417532033728F353040000 revoked successfully. ``` # Active Directory {% hint style="warning" %} SCEPman Enterprise Edition only Applicable to version 3.0 and above {% endhint %} SCEPman can be configured to handle SOAP requests coming from Windows client to allow for an easy deployment option for Active Directory joined clients that can only be configured using group policies. By creating a service principal in your on-premises AD-environment, we can allow SCEPman to accept SOAP requests of a domain-joined Windows client requesting a certificate. With Kerberos being used as authentication protocol the identity of the requester can be ensured and SCEPman will respond with a valid certificate. All supported versions of Windows supports this enrollment method natively and no additional software is required on these computers. {% content-ref url="/pages/ePTTQ0eRxIkwmTBwPTu2" %} [General Configuration](/certificate-management/active-directory/general-configuration) {% endcontent-ref %} {% content-ref url="/pages/iiZzMs0u0rdCY8R6d5ox" %} [Group Policy](/certificate-management/active-directory/group-policy) {% endcontent-ref %} # General Configuration To allow SCEPman to handle incoming SOAP requests successfully, we need to take a few steps: {% stepper %} {% step %} ### Custom Domain For successful authentication with SCEPman, ensure that a custom domain using an `A record` is pointed to the App Service. Otherwise, the client will fail to request a valid Kerberos ticket from the domain controller. {% hint style="info" %} The custom domain does not have to resemble the FQDN of your AD domain. So having a domain `ad.contoso.local` does not mean you need an identical or similar custom domain for SCEPman. See the known issue below regarding [WS\_E\_ENDPOINT\_ACCESS\_DENIED](https://app.gitbook.com/o/-LhPlvZ6dc8XcqY7tdZw/s/-LoGejQeUQcw7lqnQ3WX/~/diff/~/changes/806/certificate-management/active-directory/general-configuration#ws_e_endpoint_access_denied) for more information. {% endhint %} Ensure that SCEPman is configured to be accessible using a custom domain: {% content-ref url="/pages/JJWmkIqLTr0mMGfbt5Ly" %} [Custom Domain](/azure-configuration/custom-domain) {% endcontent-ref %} {% endstep %} {% step %} ### BaseUrl To allow successful authentications, make sure the [AppConfig:BaseUrl](https://app.gitbook.com/o/-LhPlvZ6dc8XcqY7tdZw/s/-LoGejQeUQcw7lqnQ3WX/~/diff/~/changes/806/scepman-configuration/application-settings/basics#appconfig-baseurl) variable matches your custom domain. | Setting | Value | | ----------------- | ---------------------------- | | AppConfig:BaseUrl | Example: scepman.contoso.com | **Alternatively**, if you prefer accessing the AD Endpoint using a different URL from your other SCEPman endpoints, use the dedicated [AppConfig:ActiveDirectory:BaseUrl](https://app.gitbook.com/o/-LhPlvZ6dc8XcqY7tdZw/s/-LoGejQeUQcw7lqnQ3WX/~/diff/~/changes/806/scepman-configuration/application-settings/active-directory/general#appconfig-activedirectory-baseurl) setting. | Setting | Value | | --------------------------------- | ------------------------------- | | AppConfig:ActiveDirectory:BaseUrl | Example: adendpoint.contoso.com | | {% endstep %} | | {% step %} ### Create Service Principal Use the `New-SCEPmanADPrincipal` Cmdlet of the SCEPman PowerShell module to create the service principal in your on-prem Active Directory domain. It will also export a keytab from this account and encrypt it to SCEPman's CA certificate. You can execute this command on a domain controller or domain-joined server that has installed the `RSAT-AD-Tools` feature. You will also need the following permissions in the OU that you want to create the principal in: On OU itself: * Create computer objects On descendant computer objects: * Reset password * Write `msDS-SupportedEncryptionTypes` * Write `servicePrincipalName` * Write `userPrincipalName` The variant below also requires outgoing HTTPS network access to your SCEPman instance. {% hint style="info" %} If your computer with access to a Domain Controller doesn't have network access, there are variants of the CMDlet that work without it, but require some additional preparation, such as downloading the SCEPman CA certificate and copying the CA to the machine that runs the CMDlet. {% endhint %} ```powershell Install-Module SCEPman -Force New-SCEPmanADPrincipal -Name "SCEPmanAD" -AppServiceUrl "scepman.contoso.com" -OU "OU=Example,DC=contoso,DC=local" ``` Running this command will perform the following: 1. Create a computer object in the `OU=Example,DC=contoso,DC=local` Organizational Unit. 2. Download SCEPman's CA certificate to encrypt the keytab in step 5. 3. Add a service principal name (SPN) to the computer object. 4. Create a keytab for the computer account containing the encryption key based on the computer's password. 5. Encrypt the keytab with the CA certificate of SCEPman, so only SCEPman can decrypt it again using the CA private key. 6. Output the encrypted keytab, so it can be transferred to SCEPman's configuration. The Base64 encoded output must then be added to the environment variable **AppConfig:ActiveDirectory:Keytab** on your SCEPman App Service. {% endstep %} {% step %} ### Add Keytab to SCEPman The integration can easily be enabled by adding the following environment variables in the **SCEPman App Service.** Depending on your use case, enable one or more of the available certificate templates: *Example with all certificate templates enabled:* | Setting | Value | | -------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | | [AppConfig:ActiveDirectory:Keytab](appconfig:ActiveDirectory:Keytab) | Base64 encoded keytab for the service principal created in [Step 3](/certificate-management/active-directory/general-configuration#create-service-principal) | | [AppConfig:ActiveDirectory:Computer:Enabled](/scepman-configuration/application-settings/active-directory/computer-template#appconfig-activedirectory-enabled) | true | | [AppConfig:ActiveDirectory:User:Enabled](/scepman-configuration/application-settings/active-directory/user-template#appconfig-activedirectory-enabled) | true | | [AppConfig:ActiveDirectory:DC:Enabled](/scepman-configuration/application-settings/active-directory/dc-template#appconfig-activedirectory-enabled) | true | | [AppConfig:ActiveDirectory:RdpServer:Enabled](/scepman-configuration/application-settings/active-directory/rdp-template#appconfig-activedirectory-enabled) | true | | {% endstep %} | | | {% endstepper %} | | ## Known Issues ### WS\_E\_ENDPOINT\_ACCESS\_DENIED ``` Error: WS_E_ENDPOINT_ACCESS_DENIED Hex: 0x803d0005 Dec: -2143485947 ``` This error is known to occur during the validation of the CEP server when you are using the *default* URIs of the Azure App Service. This error is caused by the Kerberos protocol asking for a service principal name of the `A record` of the service that is to be accessed. In the case of the default app service domains, for example `contoso.azurewebsites.net` is a `CNAME` and points to an `A record` similar to: ``` waws-prod-ab1-234-c56d.westeurope.cloudapp.azure.com ``` As this `A record` of an infrastructure host is not guaranteed to be consistent in the future, adding a service principal name for this host is **not recommended**. Make sure to add a custom domain to your app service and use an `A record` within your DNS provider to point it to the app service instead of a `CNAME`. {% content-ref url="/pages/JJWmkIqLTr0mMGfbt5Ly" %} [Custom Domain](/azure-configuration/custom-domain) {% endcontent-ref %} ### ERROR\_INVALID\_PARAMETER ``` Error: ERROR_INVALID_PARAMETER Hex: 0x80070057 Dec: -2147024809 ``` This error occurs during the CEP server registration if you enter an URI that begins with `http://`. Make sure to only register a CEP server using `https://` . ### ERROR\_ACCESS\_DENIED ``` Error: ERROR_ACCESS_DENIED Hex: 0x80070005 Dec: -2147024891 ``` When registering a CEP server in machine context, the acting user (the account that started `gpmc.msc`) needs to be a member of the local Administrators group on the computer while editing the GPO. Make sure to start `gpmc.msc` with elevated permissions in this case. # Group Policy This certificate enrollment founds on the [XCEP](https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-xcep) and [WSTEP](https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-wstep/) protocols that all recent Windows versions natively support. In Active Directory environments, the necessary settings can be applied via group policies (GPO), to make AD-joined computers enroll certificates from SCEPman. In this scenario, three group policy settings are required for a fully automated certificate deployment. {% stepper %} {% step %} ### Registration of the CEP server The CEP (Certificate Enrollment Policy) server (part of SCEPman) will provide an authenticated client a policy containing all certificate templates configured on SCEPman for Active Directory enrollment. The CEP server needs to be added on the clients in the registry. Windows includes GPO templates to configure the necessary settings in the GUI. #### Policy Configuration For the certificate templates `Device` and `DC`, you have to go into the *Computer Configuration* hive. For `User`, navigate in the *User Configuration* hive. If you use certificate templates of both kinds, you'll have to configure both. In that case, you'll usually use two GPOs, one applied to the users with the User Configuration and one applied to computers with the Computer Configuration. 
Computer Configuration / User Configuration
└-Policies
  └-Windows Settings
    └-Security Settings
      └-Public Key Policies
        └-Certificate Services Client - Certificate Enrollment Policy Server
In the setting, add a new CEP server in the list and enter the policy server URI in the respective input. You can copy this URI from your SCEPman's homepage. It follows the scheme of `https://scepman.contoso.com/step/policy`. After entering and validating the CEP server you can finish the setting by adding it and confirming the dialog. {% hint style="warning" %} In the configuration process, the client already makes a validation call to the CEP server. Therefore, the account context used for the configuration must have permission to access SCEPman's CEP endpoint, i.e. authenticate with Kerberos, and outgoing network access to SCEPman port 443. {% endhint %}
{% hint style="warning" %} Please see the [Known Issues](/certificate-management/active-directory/general-configuration#known-issues) section in case you receive an error during the CEP server validation. {% endhint %}
{% hint style="info" %} If you are using the SCEPman CEP server in parallel to your existing ADCS, you need to choose a default server and make sure you keep the existing enrollment policy. {% endhint %} {% endstep %} {% step %} ### Enable Auto-Enrollment With the registered CEP server, your users/computers can request certificates from SCEPman. Usually, you want them to do this automatically without user interaction and for this, you have to enable Auto-Enrollment. Note that it may already be enabled if you were using Autoenrollment before with Microsoft Active Directory Certificate Services (AD CS). 
Computer Configuration / User Configuration
└-Policies
  └-Windows Settings
    └-Security Settings
      └-Public Key Policies
        └-Certificate Services Client - Auto-Enrollment
Make sure to check `Update certificates that use certificate templates` to enable the automatic enrollment.
{% endstep %} {% step %} ### Install Trusted Root CA With the enrollment policy server and auto-enrollment settings in place, you just need to make sure that your target devices or users are trusting your SCEPman CA certificate. For this to happen you will need to import the CA certificate in the corresponding GPO setting. 
Computer Configuration / User Configuration
└-Policies
  └-Windows Settings
    └-Security Settings
      └-Public Key Policies
        └-Trusted Root Certificatin Authorities
          └- Import (Context Menu)
Download your SCEPman's CA certificate from its homepage and make sure to import it in this dialogue. {% endstep %} {% endstepper %} # Scenarios # RDP Server Certificate Using the `RdpServer` template, you can configure computers and servers to make use of managed certificates provided to clients accessing them through the Remote Desktop Protocol. {% stepper %} {% step %} ### Create Template Object in Active Directory During the enrollment and mapping of the certificate, the `SessionEnv` service will lookup the configured certificate template in Active Directory even if the certificate template will be used from the already configured CEP service of SCEPman. To satisfy this lookup we will create an empty certificate template object in the expected location. This requires write permissions to the Public Key Services container in the Forest, for example with the role Enterprise Admin. {% hint style="info" %} An Enterprise Admin is required to perform this object creation — unless you have assigned permissions to further roles on the Public Key Services container. {% endhint %} {% code lineNumbers="true" %} ```powershell $ConfigPath = (Get-ADRootDSE).configurationNamingContext $TemplateContainer = "CN=Certificate Templates,CN=Public Key Services,CN=Services,$ConfigPath" $Name = "SCEPmanRdpServer" New-ADObject -Name $Name ` -Type pKICertificateTemplate ` -Path $TemplateContainer ` -OtherAttributes @{ "displayName" = $Name; "msPKI-Cert-Template-OID" = "1.3.6.1.4.1.311.21.8.$(Get-Random 9999999).$(Get-Random 9999999)"; "msPKI-Template-Schema-Version" = 1; "msPKI-Template-Minor-Revision" = 1; "msPKI-RA-Signature" = 0; "flags" = 0 } ``` {% endcode %} {% endstep %} {% step %} ### Enable Certificate Template in SCEPman Like other certificate templates, this one can be configured by adding the following environment variables to the the SCEPman app service: | Setting | Value | Description | | ----------------------------------------------- | --------- | -------------------------------------------------------------------------------------- | | AppConfig:ActiveDirectory:RdpServer:Enabled | true | Enable the certificate template | | AppConfig:ActiveDirectory:RdpServer:GroupFilter | Group SID | Optional: Only allow members of this group to enroll certificates using this template. | | {% endstep %} | | | {% step %} ### Configure Group Policy In a Group Policy we configure the certificate template name and instruct machines additionally to enforce a specific security layer during instructions. 
Computer Configuration

└-Policies
  └-Administrative Templates
    └-Windows Components
      └-Remote Desktop Services
        └-Remote Desktop Session Host
          └-Security
            └-Server authentication certificate template
            └-Require use of specific security layer for remote (RDP) connections
#### Server authentication certificate template Enter the name of the certificate template to be used for RDP server authentication. By default, this is `SCEPmanRdpServer`.
#### Require use of specific security layer for remote (RDP) connections Select SSL here to enforce the use of the used certificate.
{% endstep %} {% endstepper %} With the configuration in place, the `SessionEnv` service can be restarted to enforce the enrollment and mapping of the certificate. On the computer itself, you can confirm the used certificate by running the following command: {% code overflow="wrap" %} ```powershell (Get-CimInstance -Class Win32_TSGeneralSetting -Namespace root\cimv2\terminalservices -Filter "TerminalName='RDP-tcp'").SSLCertificateSHA1Hash ``` {% endcode %} This will output the thumbprint of the active RDP certificate. The event log will also show that a new certificate has been used: {% code title="Show relevant event log entries" overflow="wrap" %} ```powershell Get-WinEvent -LogName "System" | Where-Object { $_.ProviderName -eq "Microsoft-Windows-TerminalServices-RemoteConnectionManager" } | Select-Object -First 10 | Format-List Message, TimeCreated ``` {% endcode %} > A new template-based certificate to be used by the RD Session Host server > \ > for Transport Layer Security (TLS) 1.0\Secure Sockets Layer (SSL) > \ > authentication and encryption has been installed. The name for this > \ > certificate is svr01.Conitoso.local. The SHA1 hash of the certificate is > \ > provided in the event data. # Application Insights {% hint style="info" %} We recommend enabling Application Insights to receive a graphical representation of data about your SCEPman instance such as Failed requests, Availability, and Server response time over a given duration. {% endhint %} To activate the Application Insights for your App Service, please follow these instructions: {% stepper %} {% step %} ### Navigate to your SCEPman App Service Azure > App Services > app-scepman-xxxxxx {% endstep %} {% step %} ### Select and Turn on Application Insights On the lefthand menu, expand Monitoring > Application Insights \ ![](/files/xzZNA28BX3PkW8eUD9yd) {% endstep %} {% step %} ### Create a new Application Insights resource
For Windows based deployments, select **.NET** and select the **Collection level Recommended.** (For Linux based deployment, please choose **.NET Core**) **Profiler** and **Snapshot debugger** should be turned on by default already. Leave **Show local variables \[...]** as *Off*, otherwise, Application Insights may cause startup delays and error messages.
{% endstep %} {% step %} ### Apply settings You're now set to use Application Insights for SCEPman! {% endstep %} {% endstepper %} # App Service Sizing ## Basics SCEPman depends mainly on the CPU resources. Memory and disk are much less important. One SCEPman instance (version 3.0 and newer) in one Azure P0V3 App Service Plan (195 ACUs) can serve around 4000 requests per minute under usual conditions. Requests are * SCEP issuing requests and * OCSP requests. This means that SCEPman can serve about 20 requests per minute per ACU. Since a certificate is enrolled once, but its validity is checked many times, there will be much more OCSP requests than SCEP requests in total. Hence, you should size your SCEPman instance based on your OCSP requests. ## Dependencies The load for your SCEPman service has several dependencies and varies in the different environments. Important dependencies are: 1. Distribution of requests 2. Frequency of logins to network resources 3. Frequency of certificate requests/renewals Especially the distribution of the requests has a high importance. If all clients do requests at the same time, your SCEPman instances get heavy load. You should strive to let SCEPman answer to SCEP requests in less than a minute in all cases. {% hint style="warning" %} Please do not assign SCEP profiles to a large number of users/devices at once, since this may result in a request-peak at your SCEPman instances. {% endhint %} ## Recommendation We recommend the following sizing in Azure Compute Units (ACU) for the Azure App Service Plans as a starting point: | Amount of users/clients | Singular design | Geo-Redundant design | | :---------------------: | :--------------------------------------: | :----------------------------------------------: | | < 5000 clients |

\~100 ACUs
(e.g. 1 x S1)

|

2 x \~100 ACUs

(e.g. 2 x S1)

| | < 10.000 clients |

\~200 ACUs

(e.g. 1 x P0V3)

|

2 x \~200 ACUs

(e.g. 2 x P0V3)

| | < 25.000 clients |

\~400 ACUs

(e.g. 2 x P0V3)

|

2 x \~400 ACUs
(e.g. 4 x P0V3)

| | < 50.000 clients |

\~800 ACUs

(e.g. 4 x P0V3)

|

2 x \~800 ACUs
(e.g. 8 x P0V3)

| | < 100.000 clients |

\~1600 ACUs

(e.g. 4 x P1V3)

|

2 x \~1600 ACUs

(e.g. 8 x P1V3)

| | > 100.000 clients |

\~3200 ACUs

(e.g. 4 x P2V3)

|

2 x \~3200 ACUs

(e.g. 2 x 4 x P2V3)

| Based on these recommendations, you can monitor your traffic and see whether you can scale down as described in the Section [Fine Tuning](#fine-tuning) below. ## Azure Cost Prognosis The main Azure costs will be for the Azure Apps Service Plan(s). You can derive your cost from the requirements in the table above and [your Azure pricelist](https://azure.microsoft.com/en-us/pricing/calculator/) or the generic undiscounted [App Service Pricing](https://azure.microsoft.com/en-us/pricing/details/app-service/windows/) overview. The additional Azure resources (Key Vault, Storage Account, Log Analytics, network resources for private endpoints) play a minor role in the cost. Depending on the use cases in your environment, you should expect an additional 5% to 25% on top of the App Service Plan cost for these additional Azure resources. {% hint style="info" %} This cost projection is just a rule of thumb to help you estimate the cost of Azure. It can vary significantly in different environments. {% endhint %} ## Fine Tuning Every environment has its own load distribution over the day. In many environments the morning (start of work) generates a peak in terms of load at your SCEPman. ### Manual Scale You can adapt the computing power for your App Service to your individual daily load distribution with the Azure App Service Scale Out features. E.g. you could define 2 x S1 in the morning from 08:00-10:00 to cover the morning peak, while you reduce to 1 x S1 for the rest of the day. ### Auto Scale Alternatively you can use the Azure App Autoscaling feature to adapt to needed resources. Learn more about that in [Autoscaling](/azure-configuration/azure-sizing/autoscaling). ### Manual vs. Auto Scale If you are able to predict your load well (e.g. derived from load history), we recommend Manual Scale over Auto Scale, since Auto Scale has to behave lazy (hysteresis) to prevent flapping between scales. # Autoscaling Autoscaling automatically adjusts the number of running instances based on demand to maintain performance and control costs. ## Instructions {% stepper %} {% step %} ### Navigate to your App Service Plan's Autoscale Settings Azure Portal > App Service Plans > *Your SCEPman App Service Plan* > Settings > Scale out
{% hint style="warning" %} Please ensure that your App Service plan uses at least the **S1 or P0V3** pricing tier. Lower tiered plans may not provide multiple instances. {% endhint %} {% endstep %} {% step %} ### Select Rules Based Autoscaling Select **Rules Based**, then **Configure** to proceed.
{% endstep %} {% step %} ### Configure Autoscale Settings To scale the instance count based on the current load of the service there must be two scaling rule conditions added. One rule to increase the instance count on heavy load and one rule to decrease the instance count after the load is reduced again.
1. Select **Custom autoscale** 2. Type in an appropriate name in **Autoscale setting name** 3. Select **Scale based on a metric** to enable autoscaling based on a defined rule set 4. Set the instance limits in line with your business requirements: * Minimum * Maximum * Default 5. Select **Add a rule** once you're ready to configure your Autoscaling rules {% endstep %} {% step %} ### Configure Autoscaling Rules {% hint style="info" %} We recommend the following settings of the increase and decrease rules.\ But please keep in mind that this can depend on your workload and needs to be monitored and optimized! {% endhint %} #### Increase Instance Count Rule 1. **Enable metric divided by instance count** 2. Choose **Greater than** as the Operator and set the threshold to **70** (percent) 3. Set the duration to **10** (minutes) 4. Ensure that the **Time grain statistic** is set to **Average** 5. Ensure that the **Operation** is set to **Increase count by** 6. Set the **Cool down (minutes)** to **15** (minutes) 7. Check the **Instance count (1)** that will be added to the current instances 8. Click **Add** when done
#### Decrease Instance Count Rule 1. Select **Add a rule** to add an additional rule 2. **Enable metric divided by instance count** 3. Choose **Less than** as the Operator and set the threshold to **35** (percent) 4. Set the duration to **20** (minutes) 5. Ensure that the **Time grain statistic** is set to **Average** 6. Ensure that the **Operation** is set to **Decrease count by** 7. Set the **Cool down (minutes)** to **30** (minutes) 8. Check the **Instance count (1)** that will be removed from the current instances 9. Click **Add** when done
{% endstep %} {% step %} ### Save Autoscale Settings Congratulations! Your App Service Plan will now scale up and down in accordance with your rules.
{% endstep %} {% endstepper %} # Backup Considerations By default, SCEPmans Azure resources offer built-in data resiliency and high availability features, reducing the need for manual backup processes in typical deployments. However, in certain edge cases—such as compliance requirements, custom configurations, or specific recovery objectives—manual or supplementary backup strategies may be necessary. In these scenarios, the following backup considerations and plans should be followed to ensure data protection and business continuity. ## Key Vault ### Backup Any Key Vault certificate can be backed up by navigating into it and clicking the `Download Backup` button:
{% hint style="warning" %} **Considerations**: * The backup of this certificate will be encrypted to Azure Key Vault and can only be restored in Azure Key Vault within the same subscription * At least *Key Vault Contributor* role required {% endhint %} ### Restore A back upped Key Vault certificate can be restored in any Key Vault of the same subscription using the `Restore Backup` function in the its Certificate store:
{% hint style="warning" %} **Considerations**: * A backup of a HSM key can only be restored on a Key Vault of Premium SKU * The restoring account needs to have at least the role of *Key Vault Contributor* {% endhint %}
# Custom Domain ## Custom Domain Configuration If you want to create your own custom domain for your **SCEPman App Service** URL, you have to decide whether you want to add it because it is a requirement to activate the Active Directory Endpoint or only for other reasons. #### Considerations for an Active Directory Endpoint If you want your custom domain for the [Active Directory](/certificate-management/active-directory) endpoint, you need to create an **A record**, because [Kerberos requires this](/certificate-management/active-directory/general-configuration#ws_e_endpoint_access_denied). In this case, you must choose "All other domain services", even if you have an App Service Domain. The UI might force you to select **CNAME** as record type depending on your other selections. We have successfully tested that you can still configure the DNS entry as an **A record** and found no problems with this configuration. Otherwise change your settings, such that an **A record** is allowed like using an apex domain or using a certificate other than the App Service Managed Certificate. In this case, you need to find out the inbound IP address of your App Service, which is displayed in the Networking entry of the App Service.
#### **Adding the Custom Domain** If you are using Azure Domain Services, select "App Service Domain" to benefit from its native integration with App Services. If you are not using Azure Domain Services, choose "All other domain services" and add the required validation records with your domain provider: {% hint style="info" %} For "Domain validation" please note: * Check for possible **CAA records** on the root domain (specifies which Certificate Authorities (CAs) are authorized to issue certificates) - see [certificate requirements](https://learn.microsoft.com/en-us/azure/container-apps/custom-domains-managed-certificates?pivots=azure-portal#free-certificate-requirements) * [Important Changes to App Service Managed Certificates](https://techcommunity.microsoft.com/blog/appsonazureblog/follow-up-to-%E2%80%98important-changes-to-app-service-managed-certificates%E2%80%99-november-20/4466120) {% endhint %} ![](/files/nn0rKE3XYXmH3rXqurRs) ### Configure the BaseUrl of SCEPman {% hint style="info" %} When you add the Custom Domain to enable the Active Directory Endpoint, as an alternative to updating the BaseUrl configuration as described below, you can also change the setting [AppConfig:ActiveDirectory:BaseUrl](/scepman-configuration/application-settings/active-directory#general-settings). This won't affect things like your AIA, but only the Active Directory endpoints. {% endhint %} After configuring the custom domain, make sure to update SCEPman App Service Setting [**AppConfig:BaseUrl**](/scepman-configuration/application-settings/basics#appconfig-baseurl) to the new URL, save and restart the App Service. ![](/files/-MCkOC3NgeX_VjuNyCON) {% hint style="info" %} It is not recommended to set a custom domain to Certificate Master. If you still want to set it up, make sure to also do: * in SCEPman App Service Configuration, update **`AppConfig:CertMaster:URL`** to the new Certificate Master URL * add the new sign-in URL to the Certificate Master app registration "SCEPman-CertMaster". {% endhint %} #### Microsoft Documentation and Managed Certificates Add a custom domain to an App Service:\ Add and manage TLS/SSL certificates in App Service:\ # Geo-Redundancy {% hint style="warning" %} SCEPman Enterprise Edition only {% endhint %} This reference architecture shows how to run an Azure App Service application in multiple regions to achieve high availability. {% hint style="info" %} Geo-redundancy / high-availability is currently only available for (main) SCEPman App Service. Rationale: The users of Certificate Master are administrators with typically non-time-critical certificate workloads and knowledge of procedures to handle such scenarios. {% endhint %} ## Architecture ![](/files/m4mwBXOGQ7YFb6GB92Jl) As illustrated above, the geo-redundant deployment leverages an Azure Traffic Manager profile, that routes (DNS-based) requests to the SCEPman CA to a pair of SCEPman instances that are deployed in different geolocations. The individual SCEPman instances communicate with the same KeyVault, Storage Account and AAD and thus share the same Root CA. Besides load-balancing traffic based on a set of routing algorithms that you can choose from, Traffic Manager also constantly probes both instances of SCEPman. In case an instance becomes unavailable, all traffic will automatically be routed to the available instance. Microsoft discusses in [this article](https://docs.microsoft.com/en-us/azure/architecture/reference-architectures/app-service-web-app/multi-region) three different Geo-Redundancy strategies that can be used to manage this type of architecture. However, In our case, we will use the **Active/Active** approach. This means both regions are active, and requests are load-balanced between them. If one region becomes unavailable or has some latency for any reason, Traffic Manager will route the traffic to the second App Service. {% hint style="info" %} Make sure to take a look at [Microsofts list of available regions](https://learn.microsoft.com/en-us/azure/reliability/regions-list#azure-regions-list-1) and their corresponding paired region. Using unpaired regions can lead to issues during the setup of this redundancy. {% endhint %} ## Workflow * First, the SCEPman App Service will be cloned into another geolocation. * Then, the Traffic Manager is configured and its Endpoints are added and connected to both SCEPman App Services. * Then, the custom domains for both App Services are configured. * Finally, the DNS CNAME record is configured, pointing your custom domain to the Traffic Manager. ### Clone App To clone an App Service, first you need to create a new **App Service Plan** in a second geolocation, this is where the cloned App will be deployed. You can create it in the same SCEPman Resource group or in a new one. See screenshot below: ![Creation of a new App Service Plan with Windows](/files/JtUml6eM2h3MlBMCuvCt) {% hint style="info" %} App Service Clone requirements (via [SCEPman PowerShell Module](/scepman-deployment/permissions/post-installation-config#acquire-and-run-the-scepman-installation-powershell-module)): * SCEPman **2.2** or above * SCEPman PowerShell Module **1.6.3.0** or above * Global Admin permissions {% endhint %} The following CMDlet command will clone your SCEPman App Service and configure all required permissions: ``` New-SCEPmanClone -SourceAppServiceName -TargetAppServiceName -TargetAppServicePlan -SearchAllSubscriptions 6>&1 ``` * **SourceAppServiceName:** The name of the existing SCEPman App Service. * **TargetAppServiceName:** The name of the newly cloned SCEPman App Service. * **TargetAppServicePlan:** The name of the App Service Plan for the cloned SCEPman instance. The App Service Plan must exist already in the TargetResourceGroup. * **SourceResourceGroup:** (Optional) The Azure resource group hosting the existing SCEPman App Service. Leave empty for auto-detection. * **TargetResourceGroup:** (Optional) The Azure resource group hosting the new SCEPman App Service. Leave empty to auto-detect the resource group of the App Service Plan. * **SourceSubscriptionId:** (Optional) The ID of the Subscription where SCEPman is installed. Can be omitted if it is pre-selected in az already or use the SearchAllSubscriptions flag to search all accessible subscriptions * **TargetSubscriptionId:** (Optional) The ID of the Subscription where SCEPman shall be installed. Can be omitted if it is the same as SourceSubscriptionId. * **SearchAllSubscriptions:** (Optional) Set this flag to search all subscriptions for the SCEPman App Service. Otherwise, pre-select the right subscription in az or pass in the correct SubscriptionId. ### **Example** Clone an existing SCEPman App Service "as-scepman-nrg5reuov63vk" ``` New-SCEPmanClone -SourceAppServiceName as-scepman-nrg5reuov63vk -TargetAppServiceName as-scepman-clone -TargetAppServicePlan asp-scepman-geo2 -SearchAllSubscriptions 6>&1 ``` ![](/files/IOAIbhxN9VUBrgWtbCXL) After the deployment has finished successfully, navigate to the cloned App Service and check the SCEPman homepage that all permissions are set correctly and everything is green and connected (this could take up to 3 minutes after the deployment is done). ![](/files/Ua4cgAKVJ99Y8NGlNJ9z) {% hint style="info" %} To avoid a single point of failure, we recommend setting the [WEBSITE\_RUN\_FROM\_PACKAGE](/scepman-configuration/application-artifacts) of the cloned App Service to the second independent artifact host on Azure. Production channel: `https://install.scepman.com/dist/Artifacts.zip` The original App Service should have the first artifact host by default, which points to a GitHub repository. For more information please check [Application Artifacts](/scepman-configuration/application-artifacts). {% endhint %} {% hint style="warning" %} Cloning an App Service has some restrictions such as **autoscale** settings, **backup schedule** settings, **App Insights**, etc.. Configurations that cannot be cloned, must be manually configured again on the cloned App Service. Additionally, changes to the settings of one AppService will not be synchronized automatically to the second App Service if performed after the cloning operation. For more info visit {% endhint %} ### Setup Traffic Manager Follow the steps below to create and configure the Traffic Manager and balance the traffic between both SCEPman instances: 1. Search in the Marketplace for **Traffic Manager profile** and click **Create**. 2. Fill in the fields and choose your SCEPman resource group ![](/files/-MdzbkWhmijYC6nEr4JT) 1. Then click **Create**. 2. After your Traffic Manager is deployed, open it and click on **Configuration** 3. Change the settings as follows and save ![Traffic Manager Configuration](/files/bXwb1i4IEL1sRgPccSUL) #### Adding Endpoints #### First Endpoint 1. Then under **Settings** choose **Endpoints** 2. Choose "Azure Endpoint" as **Type**, provide a name for the first Endpoint, and "App Service" as **Target resource type** 3. Choose your primary SCEPman App Service as **Target resource** ![Traffic Manager, Endpoint Configuration](/files/-LoGez6cNc9nF9Efgzht) #### Second Endpoint Repeat the same steps for the second endpoint and choose the second (cloned) SCEPman App Service as a **Target resource** ### Custom Domain Configuration After a successful deployment and configuration of the Traffic Manager Endpoints, you need to set up the **same** custom domain for **both** SCEPman instances as described [here](/azure-configuration/custom-domain). Make sure to change the value of the setting **AppConfig:BaseUrl** for **both** SCEPman App Services after the custom domains have been created. ### DNS Configuration In the Traffic Manager **Overview,** you will find the DNS name, that needs to be added to your DNS ![Traffic Manager Overview](/files/-MdzaiMC44cY5CNItKUZ) * Navigate to your DNS management service (e.g. **Azure DNS Zones**) * Remove any possibly existing wrong CNAME entries pointing to one of the Azure App Service instances and add a CNAME that maps the created SCEPman custom domain to the Traffic Manager DNS name. In the example below the CNAME should point to **gk-blueprint-scepman.trafficmanager.net**. {% hint style="info" %} In **Azure DNS Zone**, in order to modify a record, you first have to remove the DNS lock by navigating to **Locks**. {% endhint %} {% hint style="info" %} Upon completing the configuration, ensure to update the SCEP Server URL in your SCEP profile(s) in Intune. The new URL should be the custom domain you've created with "/certsrv/mscep/mscep.dll" at the end. Example: {% endhint %} ### Storage Account Geo-Redundancy The Storage Account used for SCEPman should also be configured for redundancy. The default SCEPman setup uses Locally Redundant Storage (LRS), which uses only a single region. For example, configure Geo-redundant storage (GRS). ![Storage account redundancy dialog on Azure Portal](/files/Fcc7UyOlEMvHY74FIpuN) # Health Check You can monitor the health of SCEPman using * the [Health check feature of the Azure App Services](#health-check-in-azure-app-services) (recommended) or * a [3rd party monitoring tool](/azure-configuration/health-check/using-3rd-party-monitoring). ## Health Check in Azure App Services {% hint style="info" %} New SCEPman installations add the Health Check automatically during installation, starting with SCEPman 2.11. If you have installed SCEPman before this, you can add the health check manually using the guidance below. {% endhint %} You may configure the health check feature and corresponding alerting for the App Service to get a direct notification in case your SCEPman instance is no longer responsive. ### Configure Health Check 1. Navigate to your **App Service** and on the left side scroll down to **Health check** 2. Now you can **Enable** the Health check, as probing **path** enter the following: **/probe** 3. Now you can click on **Save**, but keep in mind that **this will restart your App Service** ![Enable Health check](/files/OKyuzmsSIh1Ul9ac3AAN) ### Configure Alerting To get an alert from our health check we need to configure alert rules in our App Service. 1. Navigate to your **App Service** and on the left side scroll down to **Alerts** 2. Click on **Create alert rule** 3. In your new alert rule, you will be automatically redirected to **Add condition** 4. Select a signal logic. Search for **Health check status** ![Create alert rule](/files/raTPMGEE9JDAfwaZI1UW) 5. Configure the alert as specified below: | **Threshold** | Static | | -------------------- | ---------- | | **Aggregation type** | Average | | **Operator** | Less than | | **Unit** | Count | | **Threshold value** | 70 | | **Check every** | 5 minutes | | **Loopback period** | 15 minutes |

Alert rule condition

6. Click on **Next: Actions** 7. Select **Create action group** {% hint style="info" %} If you have existing action groups, choose **Select action groups**, select an action group and move to step 14. {% endhint %} 8. Define an **Action group name** and **Display name** ![Create action group](/files/vg3EqmyeRPAr9pyO67Qb) 9. Next to **Notifications** and add **Notification type** 10. In the window, tick the **Email** checkbox and enter the email address you wish to receive notifications on 11. Then click on **OK** 12. Enter a **Name** for the Notification type ![Set notifications to action group](/files/-MRP8p3kVrK2jLWnCIxU) 13. After that you can click on **Review + create** and then on **Create.** You will be redirected back to **Actions** in creating the alert rule 14. Next to D**etails**, configure the following * **Resource group** * **Severity** * **Alert rule name** * Enable: **Enable upon creation** * Enable: **Automatically resolve alerts**

Alert details

15. Click on **Review + Create,** then **Create**
16. View your existing **Alert rules** as shown ![View existing alert rules](/files/JV286wG4i1y5p41UZGel) # Using 3rd Party Monitoring You can use 3rd party monitoring systems to poll the /probe endpoint of SCEPman. ### URL The probe URL is: `/probe` ### Status codes * `200`: SCEPman is up & running * `5xx`: At least one SCEPman component is not working {% hint style="info" %} To avoid any impact on the performance of your SCEPman service, we recommend a minimum poll rate setting of 60 seconds. {% endhint %} # Log Management ### Enable Logging to Azure Monitor Since version 3.0, SCEPman, as well as the Certificate Master, will utilize Microsofts Log Ingestion API to write logs to Azure Monitor. This uses a concept of a Log Analytics Workspace to hold the data and allow analyzation as well as a Data Collection Rule that interfaces between the App Service and the log storage. This allows for a more modern approach including RBAC based permissions for SCEPman to access the LAW. The creation of the Log Analytics Workspace as well as the configuration of the Data Collection Rule is automatically done by running `Complete-SCEPmanInstallation` of the SCEPman PowerShell module. {% hint style="info" %} The **default retention** period for data stored in a Log Analytics Table is **30 days**. In case a different retention period is required, adjust the configuration of the Table "SCEPman\_CL" accordingly. {% endhint %} #### Reenabling Data Collector API If, for any reason, you want to reinstate the previous API to be used you can do so by removing the Log Ingestion related app service variables and again add the ones to be used by the Data Collector API. Variables to be **removed**: * [AppConfig:LoggingConfig:DataCollectionEndpointUri](https://app.gitbook.com/o/-LhPlvZ6dc8XcqY7tdZw/s/-LoGejQeUQcw7lqnQ3WX/~/edit/~/changes/787/scepman-configuration/application-settings/dependencies-azure-services/logging#appconfig-loggingconfig-datacollectionendpointuri) * [AppConfig:LoggingConfig:RuleId](https://app.gitbook.com/o/-LhPlvZ6dc8XcqY7tdZw/s/-LoGejQeUQcw7lqnQ3WX/~/edit/~/changes/787/scepman-configuration/application-settings/dependencies-azure-services/logging#appconfig-loggingconfig-ruleid) Variables to be added: * [AppConfig:LoggingConfig:WorkspaceId](https://app.gitbook.com/o/-LhPlvZ6dc8XcqY7tdZw/s/-LoGejQeUQcw7lqnQ3WX/~/edit/~/changes/787/scepman-configuration/application-settings/dependencies-azure-services/logging#appconfig-loggingconfig-workspaceid) * [AppConfig:LoggingConfig:SharedKey](https://app.gitbook.com/o/-LhPlvZ6dc8XcqY7tdZw/s/-LoGejQeUQcw7lqnQ3WX/~/edit/~/changes/787/scepman-configuration/application-settings/dependencies-azure-services/logging#appconfig-loggingconfig-sharedkey) SCEPman will automatically pick up the settings after a restart and will utilize the Data Collector API again. ## KQL Query Examples ### See Issues with Your SCEPman Instance ```kusto SCEPman_CL | where Level == "Warn" or Level == "Error" or Level == "Fatal" ``` ### Number of Issued Certificates by Endpoint in the Selected Time Frame {% hint style="success" %} This query is guaranteed to work with SCEPman 3.0 and newer when using the Log Ingestion API for logging. Changes to SCEPman that make this query unusable will be considered Breaking Changes. {% endhint %} {% tabs %} {% tab title="Log Ingestion API ( Default )" %} ```kql SCEPman_CL | where Level == "Info" and Message startswith_cs "Issued a certificate with serial number" | project Message, RequestBase = trim_end('/', replace_string(replace_string(replace_regex(RequestUrl, "(/pkiclient\\.exe)?(\\?operation=PKIOperation(&message=.+)?)?", ""),"certsrv/mscep/mscep.dll","intune"),"step/enrollment","activedirectory")) | summarize IssuanceCount = count() by Endpoint = extract("/([a-zA-Z]+)$", 1, RequestBase) ``` {% endtab %} {% tab title="Data Collector API ( Old )" %} ```kusto SCEPman_CL | where Level == "Info" and Message startswith_cs "Issued a certificate with serial number" | project Message, RequestBase = trim_end('/', replace_string(replace_string(replace_regex(RequestUrl_s, "(/pkiclient\\.exe)?(\\?operation=PKIOperation(&message=.+)?)?", ""),"certsrv/mscep/mscep.dll","intune"),"step/enrollment","activedirectory")) | summarize IssuanceCount = count() by Endpoint = extract("/([a-zA-Z]+)$", 1, RequestBase) ``` {% endtab %} {% endtabs %} Starting with SCEPman 2.8, there is always exactly one Info level log entry whose log message starts with "Issued a certificate with serial number " per issued certificate, followed by its serial number. However, due to the unsolvable [Two Armies Problem](https://en.wikipedia.org/wiki/Two_Generals%27_Problem), it can happen that the created certificate never reaches the requester or some other type of error prevents the actual enrollment. Likewise, in case of severe errors, it can happen that a log entry exists without corresponding database entry or vice versa. ### Distinct Certificates with OCSP Check {% tabs %} {% tab title="Log Ingestion API ( Default )" %} ```kusto let map_certtype = datatable(serial_start:string, readable:string) [ "40", "Intune Device", "41", "Intune Device", "42", "Intune Incompliant Device", "50", "Static", "51", "Static", "60", "Intune User", "61", "Intune User", "64", "Jamf User", "65", "Jamf User", "6C", "Jamf User on Device", "6D", "Jamf User on Device", "70", "Domain Controller", "7C", "Jamf User on Computer", "7D", "Jamf User on Computer", "54", "Jamf Computer", "55", "Jamf Computer", "44", "Jamf Device", "45", "Jamf Device" ]; SCEPman_CL | where LogCategory == "Scepman.Server.Controllers.OcspController" and Level == "Info" | where Message startswith_cs "OCSP Response" | project serial = extract("Serial Number ([A-F0-9]+)", 1, Message) | distinct serial | extend serial_start = substring(serial,0,2) | join kind=leftouter map_certtype on serial_start | summarize count() by (readable) ``` {% endtab %} {% tab title="Data Collector API ( Old )" %} ```kql let map_certtype = datatable(serial_start:string, readable:string) [ "40", "Intune Device", "41", "Intune Device", "42", "Intune Incompliant Device", "50", "Static", "51", "Static", "60", "Intune User", "61", "Intune User", "64", "Jamf User", "65", "Jamf User", "6C", "Jamf User on Device", "6D", "Jamf User on Device", "70", "Domain Controller", "7C", "Jamf User on Computer", "7D", "Jamf User on Computer", "54", "Jamf Computer", "55", "Jamf Computer", "44", "Jamf Device", "45", "Jamf Device" ]; SCEPman_CL | where LogCategory_s == "Scepman.Server.Controllers.OcspController" and Level == "Info" | where Message startswith_cs "OCSP Response" | project serial = extract("Serial Number ([A-F0-9]+)", 1, Message) | distinct serial | extend serial_start = substring(serial,0,2) | join kind=leftouter map_certtype on serial_start | summarize count() by (readable) ``` {% endtab %} {% endtabs %} # Moving Resources This guide explains how to move SCEPman resources from one subscription to a new resource group in a different subscription within the same tenant. {% hint style="warning" %} Moving SCEPman resources from **tenant to tenant** is not supported. For more information on the underlying problem, see {% endhint %} ## Preparations * Resources associated with the private endpoint cannot be moved. Therefore, if your SCEPman is using Private endpoints, the following SCEPman resources are not movable: * 1x Virtual network * 2x Private endpoints * 2x Network Interface * 2x Private DNS zone {% hint style="info" %} **Alerts and Action groups** are also not movable. In case you have any, they need to be reconfigured in the new subscription. If you are using an **App Service managed certificate** you [cannot move it](https://learn.microsoft.com/th-th/azure/azure-resource-manager/management/move-limitations/app-service-move-limitations#move-with-free-managed-certificates). Instead, delete and recreate it after moving the web app. {% endhint %} * Movable SCEPman resources are: * App Service Plan * SCEPman and Certificate Master App Services * Storage Account * Key Vault * Log Analytics Workspace #### Since Private Endpoints are not movable, you need to take the following steps (if your SCEPman is not using Private endpoints, skip these steps): * First, enable public access on the Key Vault and Storage Account and remove the private endpoints
* Then, disconnect the outbound network integration on both app services
The same applies to the Certificate Master App service. ## Moving Resources {% hint style="warning" %} After moving SCEPman resources to the new subscription, SCEPman will lose its connection to the Storage Account. To resolve this, you will need to [run the Complete-SCEPmanInstallation command](/scepman-deployment/permissions/post-installation-config#disabled-homepage). Please note that this will be the only **downtime** during the process (from moving the resources until you run the command), which should be resolved within 3-5 minutes. {% endhint %} {% hint style="warning" %} Make sure to have the [required permissions](/scepman-deployment/permissions/post-installation-config#prerequisites) to run the [*Complete-SCEPmanInstallation* CMDlet](/scepman-deployment/permissions/post-installation-config#running-the-scepman-installation-cmdlet) before moving the resources. {% endhint %} * Create a new Resource group in the target subscription. * Now move the resources. An easy way to move resources is to select them in the Resource group and choose "Move to another subscription" option
* Then you need to choose the new Subscription and Resource group, resources will be validated and moved. ## After moving SCEPman resources: * To fix the connection to the Storage Account, [run the *Complete-SCEPmanInstallation* CMDlet.](/scepman-deployment/permissions/post-installation-config#running-the-scepman-installation-cmdlet) * Now you have the option to reconfigure the private endpoints as mentioned at [Private Endpoints](https://docs.scepman.com/architecture/private-endpoints) ## Considerations regarding the location of the moved SCEPman resources * Moving resources within the same resource group location is possible. * Moving resources between different resource group locations, the resources will remain in the original location and will simply be listed in the new resource group under a different location. E.g.:
# Private Endpoints When installing SCEPman 2.8 or newer, the Storage Account and Key Vault will be connected to a VNET through Private Endpoints. Access to the data of these two Azure Resources is only possible through this VNET, unless you define exceptions. This VNET is located in the same resource group as the other SCEPman components. The SCEPman and SCEPman Certificate Master App Services are connected to the VNET and, on a network level, have access to the Storage Account and the Key Vault. After installation, there are no exceptions configured, so no other entity can access the Key Vault certificates and keys or the Table Storage of the Storage Account. If required, for example when [generating a Subordinate CA](/scepman-deployment/intermediate-certificate) or when[ querying the Storage Account](/other/faqs/general#how-can-i-programmatically-query-the-storage-account-table), you need to add exceptions under the Networking blade of the respective Azure Resource. Access to the management interface of the Key Vault and Storage Account is unaffected, i.e. you don't need to add your admin machines to the exception list to perform functions such as changing the SKU of your Storage Account or inspecting the access logs of your Key Vault. The SCEPman and SCEPman Certificate Master App Services do not have Private Endpoints, even if you install SCEPman 2.8 or newer. They can still be accessed from the Internet without networking restrictions. We recommend not restricting access to SCEPman on a networking level, as SCEPman is usually part of the infrastructure used to establish network connections and should therefore be available even if you are not yet connected. If needed, Conditional Access can be employed to limit access to SCEPman Certificate Master with various restrictions, including networking conditions. SCEPman usually does not use Conditional Access, as the two endpoints SCEP and OCSP do not use Entra authentication. However, you might use Conditional Access to restrict access to [SCEPman's REST API](/certificate-management/api-certificates). ## Azure Resources Used for Private Endpoints
TypeDescription
Virtual NetworkThe SCEPman App Services, the Key Vault, and the Storage Account connect over this VNET.
Private Endpoint (×2)One for the Key Vault and one for the Storage Account. It makes them accessible over the VNET.
Private DNS zone (×2)One for the Key Vault and one for the Storage Account. They both have an internal IP address in the VNET, for which they have a name in their respective Private DNS zone.
Network Interface (×2)One for the Key Vault and one for the Storage Account. It connects the Private Endpoint to the VNET.
## Adding Private Endpoints to Existing SCEPman Installations If you have installed SCEPman 2.7 or older, your Key Vault and Storage Account won't automatically have Private Endpoints, even if you update to SCEPman 2.8 or newer. You have to add them manually after a conscious decision. Please follow this guide to do so: {% stepper %} {% step %} ### Create Virtual Network * In the SCEPman resource group, create a new Virtual Network using default settings or as required by your organisation. This should include a **default subnet**. * Create an additional subnet in the new **Virtual Network** with default settings and set **"Subnet Delegation"** as **Microsoft.Web/serverFarms**
{% endstep %} {% step %} ### Create KeyVault Private Endpoint 1. Navigate to your SCEPman's Resource Group > **KeyVault** > Settings > Networking > Private endpoint connections, and create a private endpoint 2. Select resource type: **Microsoft.KeyVault/vaults** 3. Select your **KeyVault** by Resource and **vault** for Target sub-resource 4. Choose the virtual network and the default subnet (not the subnet created in the first step) 5. Enable **Integrate with private DNS zone** to automatically create and connect the Private DNS zone {% endstep %} {% step %} ### Create Storage Account Private Endpoint 1. Navigate to your SCEPman's Resource Group > **Storage Account** > Security + Networking > Networking > Private endpoints and create a Private Endpoint 2. By resource, set target sub-resource to **table** 3. Choose your virtual network and default subnet 4. Enable **Integrate with private DNS zone** to automatically create and connect the Private DNS zone {% endstep %} {% step %} ### Integrate SCEPman App Service 1. Navigate to **SCEPman App service** > Networking > Add virtual network integration to the **Outbound traffic configuration** by clicking on "Not configured" 2. Select the virtual network and the created subnet from the first step. 3. Uncheck the option "Outbound internet traffic" and apply
{% endstep %} {% step %} ### Integrate Certificate Master App Service * By adding the virtual network integration to the second app service, you can select the previous connection from the list, you don't have to create a new connection. * If enabled, uncheck the option "Outbound internet traffic" and apply
{% endstep %} {% step %} ### Verify Private Endpoint Approval Check both KeyVault and Storage Account Private Endpoints are in an Approved state
{% endstep %} {% step %} ### Testing and Results Once confirmed, you can disable public access for both Key Vault and Storage account.
If connected properly, the SCEPman homepage should display all its connections as "Connected"\ ![](/files/mqee4mSxOicTkkbQ5WcN) Test that your implementation of private endpoints is successful by deploying certificates using your MDM or [Certificate Master.](/certificate-management/certificate-master) {% endstep %} {% endstepper %} # Split-Tenancy {% hint style="warning" %} SCEPman Enterprise Edition only {% endhint %} ## Overview SCEPman can be set up to function from an Azure tenant separate from the Azure/Intune tenant for which it issues certificates to users and/or devices. This configuration, known as split-tenancy, is especially **helpful for MSPs** that would like to consolidate Azure infrastructure costs across their customers while maintaining a dedicated backend and unique CA for each of those customers. Split-tenancy comes along with a **major disadvantage**: [Managed Identities](/scepman-deployment/permissions/post-installation-config) can no longer be used. This means authentication against the Graph API (Azure AD and Intune) is handled using an App registration and Client secret, which has to be managed (by the MSP) as it expires. In the following, we refer to the hosting tenant as **home tenant,** while to the customer tenant as **target tenant**. SCEPman resources will exist in the **home tenant**, and the managed devices in the **target tenant** as in the graphic below:
## Configuration Steps 1. In the **home tenant**, perform a standard deployment of SCEPman/Certificate Master as described in our [Getting Started Guide](/scepman-deployment/deployment-guides). ### In SCEPman (Home Tenant) 2. Navigate to the SCEPman **App service** and then to "Settings" --> "Environment variables". Locate the following parameters and **delete** them: | Environment Variables | | --------------------------------------------------------------- | | `AppConfig:AuthConfig:ManagedIdentityEnabledForWebsiteHostname` | | `AppConfig:AuthConfig:ManagedIdentityEnabledOnUnixTime` | | `AppConfig:AuthConfig:ManagedIdentityPermissionLevel` | 3. **Rename** the following settings (**do not change their values**):
Original nameNew name
AppConfig:AuthConfig:ApplicationIdAppConfig:AuthConfig:HomeApplicationId
AppConfig:AuthConfig:TenantIdAppConfig:AuthConfig:HomeTenantId
4. Create an **App registration** in the **target tenant** as described here: [Azure App Registration](/scepman-deployment/permissions/azure-app-registration). This **App registration** will allow SCEPman to access the Azure AD and Intune directories in the **target tenant**. {% hint style="warning" %} The **client secret** generated as part of this **App registration** has an expiration and must be renewed before it expires. Please set a reminder for the renewal. {% endhint %} **Create** the following new environment variables if you haven't done that already during creation of the app registration:
NameValue
AppConfig:AuthConfig:ApplicationIdGUID of the App registration that was created before (target tenant).
AppConfig:AuthConfig:TenantIdTenant ID of the target tenant.
AppConfig:AuthConfig:ApplicationKeyValue of the Client secret that was created as part of the App registration in the target tenant.
5. Apply the changes. 6. Restart the SCEPman **App service**. ### Certificate Master 7. Navigate to the Certificate Master **App service** and then to "Settings" > "Environment variables". 8. Now you have two options: 1. If you want users from your **home tenant** to log in to Certificate Master and issue certificates, which includes guest users in your home tenant, e.g. from your target tenant.

Option 1: Users from Home Tenant log in to Certificate Master

If that is the case, **rename** the following settings (**do not change their values**):
Original nameNew name
AppConfig:AuthConfig:TenantIdAppConfig:AuthConfig:HomeTenantId
AppConfig:AuthConfig:ApplicationIdAppConfig:AuthConfig:HomeApplicationId
b. You want users from your **target tenant** to log in to Certificate Master and issue certificates, which includes guest users in your target tenant, e.g. from your home tenant.

Option 2: Users from the Target Tenant log in to Certificate Master

If that is the case, do the following: * Open a **PowerShell** or **Azure Cloud Shell** in your **target tenant** and run the following commands: ``` Install-Module SCEPman -Scope CurrentUser -Force Register-SCEPmanCertMaster -CertMasterBaseURL ``` Replace `` with your Certificate Master URL * The **CMDlet** will output an **Application Id** and a **Tenant Id** (that of the **target tenant**). Enter these two values as * `AppConfig:AuthConfig:HomeApplicationId` and * `AppConfig:AuthConfig:HomeTenantId` in your Certificate Master settings. * Now **create** the following new application settings, possibly overriding the existing ones, with the same values as in SCEPman:
NameValue
AppConfig:AuthConfig:ApplicationIdGUID of the App registration that was created before.
AppConfig:AuthConfig:TenantIdTenant ID of the target tenant.
AppConfig:AuthConfig:ApplicationKeyValue of the Client secret that was created as part of the App registration before.
You can create a separate new Client secret for Certificate Master if you want.
9. Save the changes 10. Restart the SCEPman Certificate Master **App service**. 11. Grant the rights to request certificates via the **Certificate Master** web app, see [here](/scepman-deployment/permissions/post-installation-config#granting-the-rights-to-request-certificates-via-the-certificate-master-website) As an overview, here are the accounts used by **Certificate Master** and what they are used for: | Account | What is it used for? | Notes | | ----------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------- | | Managed Identity |
  • Authorize CSRs submitted to SCEPman
  • Access to the Storage Account
| N/A | | App Registration with App ID from `ApplicationId` | Certificate Master accesses Microsoft Graph in this context to see which certificates have been enrolled via Intune | If `ApplicationKey` is not present, the Managed Identity is used instead. | | App Registration with App ID from `HomeApplicationId` | Users authenticate **to** this application. It should be in the tenant where users accessing Certificate Master reside (but guest users from other tenants can also be authorized) | If `HomeApplicationId` is not present, `ApplicationId` is used instead. | Now the Split-Tenancy configuration is finished, you can go ahead and configure your SCEP profiles based on your MDM, see [here](https://docs.scepman.com/advanced-configuration/split-tenancy#:~:text=CERTIFICATE%20DEPLOYMENT) ## Considerations when having multiple target tenants If you want to have multiple SCEPman instances to issue certificates to different target tenants you will want to take additional configuration steps to isolate these instances from each other. A possible concept could include a management resource group that holds a single App Service Plan that will provide the computing resource for all of your SCEPman App Services. The following points should be taken into consideration when doing this for multiple tenants: * Each instance should have its own resource group to distinguish them * You should create App Registrations for each instance to isolate the permissions * The App Service Plan should be created in an independent management resource group as it is serving multiple instances In this diagram a management tenant and its two SCEPman instances provide certificates to the tenants of Contoso and Tailwind: {% @mermaid/diagram content="graph LR subgraph t0\[Management Tenant] subgraph rg0\[rg-scepman-mgmt] asp\[asp-scepman-mgmt] end subgraph rg1\[rg-scepman-contoso] app1\[app-scepman-contoso] appreg1\[scepman-api-contoso] end subgraph rg2\[rg-scepman-tailwind] app2\[app-scepman-tailwind] appreg2\[scepman-api-tailwind] end end subgraph t1\[Contoso Tenant] i1\[Intune] e1\[Entra ID] end subgraph t2\[Tailwind Tenant] i2\[Intune] e2\[Entra ID] end classDef rg stroke:#6dc3d1, fill:#d5ecf2 classDef asp stroke:#2962FF, fill:#e0e7ff classDef app stroke:#fcd116, fill:#FFF8D8 classDef appreg stroke:#6DD185, fill:#ddffd8 classDef tenant stroke:#4d93c0, fill:#d0e2f0 classDef entra color:#ffffff, stroke:#0b58a4, fill:#0078d6 classDef intune stroke:#2ebddd, fill:#d9f4fa class rg0,rg1,rg2 rg class asp asp class app1,app2 app class appreg1,appreg2 appreg class t0,t1,t2 tenant class e1,e2 entra class i1,i2 intune asp --serves--> app1 asp --serves--> app2 app1 --> appreg1 appreg1 -- reads data--> i1 appreg1 -- reads data--> e1 i1 --requests certificates--> app1 app2 --> appreg2 appreg2 --reads data--> i2 appreg2 --reads data--> e2 i2 --requests certificates--> app2" fullWidth="true" %} ### Add a new SCEPman instance to an existing App Service Plan While deploying a new SCEPman instance using the [enterprise deployment method](https://docs.scepman.com/scepman-deployment/deployment-options/enterprise-deployment) you are offered the possibility to enter the resource id of an existing App Service Plan that this instance should be added to.
This resource id can be found in the properties of the existing app service plan:
### Create customer specific App registrations To isolate the apps permissions you will need to adjust the post deployment command to specify custom App Registrations: {% code overflow="wrap" %} ```powershell Complete-SCEPmanInstallation -SCEPmanAppServiceName "app-scepman-contoso" -AzureADAppNameForSCEPman "scepman-api-contoso" -AzureADAppNameForCertMaster "certmaster-contoso" -SearchAllSubscriptions 6>&1 ``` {% endcode %} This command will result in a fully configured SCEPman instance that is isolated from the prior instances. You can now go on to configure the split tenancy for this instance. The above section regarding the Certificate Master can now be applied optionally if you want this service to be accessible from the customer tenant. # Update Strategy ## Evergreen Approach We recommend an Evergreen approach for SCEPman updates. This is the default approach if SCEPman has been deployed using the production channel. SCEPman uses ZIP-Deployment by pointing directly to the [SCEPman GitHub](https://github.com/scepman) and load the latest version that is released by the development team. The production channel, along with the other available channels, are mentioned in the following guide: {% content-ref url="/pages/igMpTs5n8FHpDiHdOyt2" %} [Application Artifacts](/scepman-configuration/application-artifacts) {% endcontent-ref %} With this approach you always get the newest features and security updates. {% hint style="info" %} Keep in mind that **an update only occurs, when the App Service is stopped and started again**. This is the event when the ZIP-Deployment is triggered. While the App Service does not stop and start automatically, it is restarted externally in certain events. One of those events is the [maintenance and patching of the underlying infrastructure](https://learn.microsoft.com/en-us/azure/app-service/routine-maintenance-downtime). Those happen **regularly and keep your service up-to-date**. {% endhint %} In a production enterprise environment, if you want to have more control over the update process you can use the Microsoft feature **Deployment Slots**. ## Deployment Slot Configuration In case you want to have full control over the update process of SCEPman you can use the **Deployment Slots** within the Azure App Service. {% hint style="success" %} To get more details about the **Deployment Slots** you can visit the Microsoft docs:\ {% endhint %} The following steps give you our recommended setup for a pre-release management {% hint style="info" %} Please keep in mind that each Deployment Slot is running on the same App Service Plan of your production App and uses the same resources. {% endhint %} ### Pre-release slot The idea behind the pre-release slot is to have your production App Service running with artifacts stored on your own Storage account and create a new Deployment Slot pointing to our GitHub artifacts. You can find the steps for setting up your custom artifact location in the following article: {% content-ref url="/pages/igMpTs5n8FHpDiHdOyt2" %} [Application Artifacts](/scepman-configuration/application-artifacts) {% endcontent-ref %} Now your production App Service is running with a custom artifacts location and we proceed with the configuration of the new Deployment Slot. {% hint style="info" %} Deployment Slot requirements \*\*\*\* (via PS. SCEPman Module): * SCEPman **2.2** or above * PowerShell SCEPman-Module **1.5.1.0** or above {% endhint %} The following CMDlet command will create a Deployment Slot and configure all required permissions for you. ``` New-SCEPmanDeploymentSlot -SCEPmanAppServiceName -DeploymentSlotName 6>&1 ``` **Example** ![](/files/1K8CUXYNFmgTzCWDAzm5) After the deployment is finished successfully, you can check the deployment slot in your SCEPman App Service -> **Deployment slots** ![](/files/RSUGN6ODUWUbX8yhADwZ) Now ensure that your deployment slot points to SCEPman Production channel on GitHub: Navigate to the **Deployment Slot** -> **Environment variables** and look for the setting **WEBSITE\_RUN\_FROM\_PACKAGE** and past the [production channel artifacts](/scepman-configuration/application-artifacts#production) to the value.
If you go back to your primary **App Service** and navigate to **Deployment Slots y**ou can see your two slots and can manage the **Traffic %** to root the defined among of request to the new **pre-release** slot.\ Important that this traffic rooting is completely transparent for the application and handled by the App Service. We recommend setting the **Traffic %** to **20**. After that, you can compare the two slots in **Application Insights**. In case we are releasing an updated version to our GitHub, you only must restart the **pre-release** slot and after that, you can compare the two different versions in **Application Insights**. After one week or your choice of time, you can upload the new GitHub artifacts to your custom artifacts location and have updated the SCEPman solution. # SCEPman Settings The section describes additional settings for the behavior of SCEPman. All of these are optional, though, and we recommend just start with the defaults. Settings can be added or changed manually if needed. Some changes can harm your service. Please carefully read all information about a setting before changing. For each Setting, you can choose whether you want to define the setting in the App Service Configuration or in Azure Key Vault. If you define the same setting in both places, Azure Key Vault takes precedence. ## Convenient Configuration in the App Service Configuration
We recommend defining settings in the App Service Configuration except for passwords. ## Linux Configuration All existing settings are available for both Windows and Linux App Services. When configuring Environment Variables for Linux, colons must be replaced with two underscores. For example, a Windows App Service accepts *AppConfig:LicenseKey*, while a Linux App Service accepts *AppConfig\_\_LicenseKey.* ## Secure Configuration in Azure Key Vault Especially for sensitive information, you can also configure settings as Secrets in Azure Key Vault. You must first grant edit rights to Secrets in the Azure Key Vault associated with your SCEPman instance to an administrator account. Then, you can use this administrator account to define new Secrets. **Remark:** Use double dashes instead of colons in configuration names! For example, instead of *AppConfig:DCValidation:RequestPassword*, the Secret must be named *AppConfig--DCValidation--RequestPassword*. We recommend using this type of configuration only for sensitive information. ## List of Settings {% content-ref url="/pages/bhPopztKnAPf7l6BPhef" %} [Basics](/scepman-configuration/application-settings/basics) {% endcontent-ref %} {% content-ref url="/pages/xqfVhhNDMouvAH96x5bx" %} [Certificates](/scepman-configuration/application-settings/certificates) {% endcontent-ref %} {% content-ref url="/pages/K9x9W7G0DuvIh59l33Rn" %} [Intune Validation](/scepman-configuration/application-settings/scep-endpoints/intune-validation) {% endcontent-ref %} {% content-ref url="/pages/uRi78Qw4ESDvvapiVrig" %} [Jamf Validation](/scepman-configuration/application-settings/scep-endpoints/jamf-validation) {% endcontent-ref %} {% content-ref url="/pages/fibVgymAScyyESpOQXHW" %} [DC Validation](/scepman-configuration/application-settings/scep-endpoints/dc-validation) {% endcontent-ref %} {% content-ref url="/pages/jP0zmIFEXUW0KhUyVqgf" %} [Static Validation](/scepman-configuration/application-settings/scep-endpoints/static-validation) {% endcontent-ref %} {% content-ref url="/pages/jP0zmIFEXUW0KhUyVqgf" %} [Static Validation](/scepman-configuration/application-settings/scep-endpoints/static-validation) {% endcontent-ref %} {% content-ref url="/pages/JXQ1IRQtqlOoP0WA1RSJ" %} [Certificate Master](/scepman-configuration/application-settings/csr-validation) {% endcontent-ref %} {% content-ref url="/pages/7OdtCVGH6TWiWaOOvEV6" %} [Microsoft Entra ID (Azure AD)](/scepman-configuration/application-settings/dependencies-azure-services/azure-ad) {% endcontent-ref %} {% content-ref url="/pages/bFwuyZKlketCwYBUReq7" %} [Azure KeyVault](/scepman-configuration/application-settings/dependencies-azure-services/azure-keyvault) {% endcontent-ref %} {% content-ref url="/pages/QVQqmxmPDr4PZuHwBcXW" %} [National Cloud Platforms](/scepman-configuration/application-settings/dependencies-azure-services/national-cloud-platforms) {% endcontent-ref %} # Basics {% hint style="info" %} These settings should only be applied to the SCEPman App Service, not the Certificate Master. Please refer to [SCEPman Settings](/scepman-configuration/application-settings). {% endhint %} ## AppConfig:AnonymousHomePageAccess *Linux: AppConfig\_\_AnonymousHomePageAccess* **Value:** *true* or *false* **Description:**\ When not configured or set to **true**, anyone on the internet knowing the app service's URL can access the SCEPman Homepage and see status information like the SCEPman version and whether SCEPman is up and running (except if you prevent this with a firewall). We consider this non-sensitive information, but if you want to hide it, set this to **false**. Then, the homepage is deactivated for browser access and this information is not visible anymore. ## AppConfig:BaseUrl *Linux: AppConfig\_\_BaseUrl* **Value:** *App Service Name* or **Description:**\ This defines the public OCSP endpoint URL for the certificates. By default, the value contains the **App Service Name**. If you want to use a [Custom Domain](/azure-configuration/custom-domain), you need to change this value. ## AppConfig:LicenseKey *Linux: AppConfig\_\_LicenseKey* **Value:** *empty* **or** *license key* **Description:**\ If you are using a trial deployment or the community edition this field leaves empty. After you purchased the Enterprise Edition you will receive a license key from us, then you can insert this key into this setting. ## AppConfig:RemoteDebug *Linux: AppConfig\_\_RemoteDebug* **Example Value:** 2026-07-18 **Description:**\ You can send Debug log information to a cloud-based monitoring solution of our company for support reasons. This can speed up support cases. You can activate and deactivate this feature by changing the value to the date until when the remote debug logging should be enabled. After this date, SCEPman will keep sending debug logs until it restarts. Microsoft App Services restart automatically every now and then, usually in a two-week timeframe. We recommend setting the value to the date in one week in the format YYYY-MM-DD. For example, on 2025-05-05, you would set this to 2025-05-12. {% hint style="info" %} Do not forget to restart SCEPman App Service after enabling and saving the setting. {% endhint %} ## AppConfig:CertificateStorage:TableStorageEndpoint *Linux: AppConfig\_\_CertificateStorage\_\_TableStorageEndpoint* This defines which Table Storage Endpoint to use for checking manual certificate revocations. If you remove this setting, SCEPman will not use the database for revocation checks. {% hint style="danger" %} Changes can harm your service! {% endhint %} ## AppConfig:EnableCertificateStorage *Linux: AppConfig\_\_EnableCertificateStorage* {% hint style="info" %} Applicable to version 2.8 and above {% endhint %} **Value:** *true* or *false* (default) **Description:** When requesting certificates, SCEPman stores those requested certificates in the Storage Account in Azure if this is set to *true* and when this setting is not explicitly overridden with *false* for the specific endpoint. This will make the issued certificates appear in SCEPman Certificate Master, where you can view and revoke them manually. Additionally, certificates are revoked automatically depending on the specific SCEP endpoint used for enrollment. If set to *false* or not set, SCEPman will only store issued certificates for those endpoints where certificate storage has been explicitly enabled. If a certificate is not stored, they are visible only in the logs or if the SCEP client stores them somewhere. ## AppConfig:SCEPResponseEncryptionAlgorithm *Linux: AppConfig\_\_SCEPResponseEncryptionAlgorithm* The algorithm used to encrypt SCEP responses. Reasonable values include: * 2.16.840.1.101.3.4.1.42 for AES-256-CBC (default) * 2.16.840.1.101.3.4.1.2 for AES-128-CBC * 1.2.840.113549.3.7 for Triple DES {% hint style="danger" %} Changes can harm your service! {% endhint %} ## WEBSITE\_RUN\_FROM\_PACKAGE This setting points to the Application Artifacts that will be loaded by starting the App Service.\ Please have a look at these instructions: [Application Artifacts](/scepman-configuration/application-artifacts#change-artifacts). # Certificates {% hint style="info" %} These settings should only be applied to the SCEPman App Service, not the Certificate Master. Please refer to [SCEPman Settings](/scepman-configuration/application-settings). {% endhint %} ## AppConfig:AddMicrosoftAADExtensions *Linux: AppConfig\_\_AddMicrosoftAADExtensions* **Value:** *true* (default) or *false* **Description:** Shall certificates have the extensions 1.2.840.113556.5.14 (AAD Tenant ID) and 1.2.840.113556.1.5.284.2 (AAD Device ID)? ## AppConfig:AddSidExtension *Linux: AppConfig\_\_AddSidExtension* {% hint style="info" %} Applicable to version 2.5 and above {% endhint %} **Value:** *true* or *false* (default) **Description:** This setting determines whether certificates can have the extension 1.3.6.1.4.1.311.25.2 (user's Security Identifier (SID)). This extension is required to mitigate [Certifried attacks](/other/troubleshooting/certifried) if certificates are used for on-prem AD user authentication. If this is set to false, SCEPman will never issue certificates with this extension. If this is set to true, SCEPman may issue certificates with this extension in two cases: First, when enrolling user certificates via Intune and the user's AAD object contains a SID in the attribute *OnPremisesSecurityIdentifier*. If the user's AAD object does not contain a SID, for example if it is a cloud-only user, SCEPman will not issue a certificate with this extension. The same applies to the [static-aad endpoint](/scepman-configuration/application-settings/scep-endpoints/staticaad-validation). Second, when enrolling user certificates through other SCEP endpoints and the CSR already contains the extension. Examples are the Static SCEP endpoint and manual certificate requests through Certificate Master. ## AppConfig:ValidityPeriodDays *Linux: AppConfig\_\_ValidityPeriodDays* **Value:** *Integer* **Description:**\ The maximum number of days that an issued certificate is valid. By default, this setting is set to **730 days**. If the setting is not available (older installations of SCEPman) the validity period is **200 days**. SCEPman never issues certificates with a longer validity than the value defined here. There are ways to reduce validity for specific certificates, though. You can configure shorter validity periods in each SCEP profile in Intune as described in the [Microsoft documentation](https://docs.microsoft.com/en-us/mem/intune/protect/certificates-scep-configure#modify-the-validity-period-of-the-certificate-template). {% hint style="warning" %} iOS/iPadOS and macOS devices ignore the configuration of the validity period via Intune. Therefore, you need to configure this setting in SCEPman if you want to have another validity periods than 200 days for your iOS/iPadOS and macOS devices. Please read [iOS/iPadOS](/certificate-management/microsoft-intune/ios) for further details where we recommend a higher value. {% endhint %} You can also configure **shorter** validity periods for each SCEP endpoint. By default, the following values are set for each endpoint: | Endpoint | Parameter | Validity in days | | ------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------- | | Intune | [AppConfig:IntuneValidation:ValidityPeriodDays](/scepman-configuration/application-settings/scep-endpoints/intune-validation#appconfig-intunevalidation-validityperioddays) | 365 | | Jamf | \ | 730 (global setting) | | Static | \ | 730 (global setting) | | Certificate Master | \ | 730 (global setting) | Below image depicts how SCEPman limits the certificate validity period; first on a per-endpoint level and globally afterwards.
## AppConfig:ConcurrentSCEPRequestLimit *Linux: AppConfig\_\_ConcurrentSCEPRequestLimit* **Value:** Positive *Integer* **Default:** 50 **Description:** When more SCEP requests arrive at SCEPman, it takes longer for each request to finish. At high request frequencies, e.g. immediately after assigning a SCEP configuration profile to a large number of devices, processing the requests may take so long that the requests time out. The clients will retry their failed requests, which may keep the request frequency above the critical overload level. With this setting, SCEPman will work only on this number of SCEP requests in parallel. If there are more requests, SCEPman returns HTTP 329 (Too Many Requests). Intune-based clients will retry certificate issuance again later in this case, so usually no request is lost. This ensures that SCEPman can finish requests on time and has a chance to work off the queue. ## AppConfig:ValidityClockSkewMinutes *Linux: AppConfig\_\_ValidityClockSkewMinutes* **Value:** Positive *Integer* **Default:** 1440 **Description:** When SCEPman issues a certificate, its validity will begin 24 hours (1440 minutes) earlier than its issuance date. This is because the client's clock may run slower than SCEPman's and then assume that the certificate is not yet valid. Some platforms immediately discard invalid certificates, even if they became valid a few seconds later. ## AppConfig:UseRequestedKeyUsages *Linux: AppConfig\_\_UseRequestedKeyUsages* **Value:** *true* (default) or *false* **Description:** Should the certificates have the Key Usage and Extended Key Usage (EKU) extensions set as requested, or should SCEPman define them? **True:** The Key Usage and Extended Key Usage extensions in the certificates are defined by the MDM solution.\ **False:** Key Usage is always *Key Encipherment* + *Digital Signature*. Extended Key Usage is always *Client Authentication*. {% hint style="warning" %} iOS/iPadOS devices do not support customized Extended Key Usages (even if configured in the Intune profile and [#appconfig-userequestedkeyusages](#appconfig-userequestedkeyusages "mention") set to **True**). So, their certificates will always have *Client Authentication* as Extended Key Usage. {% endhint %} # Certificate Master {% hint style="warning" %} SCEPman Enterprise Edition only {% endhint %} {% hint style="info" %} These settings should only be applied to the SCEPman App Service, not the Certificate Master. Please refer to [SCEPman Settings](/scepman-configuration/application-settings). {% endhint %} ## AppConfig:CertMaster:URL *Linux: AppConfig\_\_CertMaster\_\_URL* **Value:** The URL of your SCEPman Certificate Master App Service **Description:** Your Certificate Master service is linked to on the SCEPman Homepage using the URL configured here. The SCEPman PowerShell module also uses this value during updates or re-configurations to link together SCEPman and its corresponding Certificate Master instance. ## AppConfig:DirectCSRValidation:Enabled *Linux: AppConfig\_\_DirectCSRValidation\_\_Enabled* **Value:** *true* or *false* **Description:** This endpoint is required for the Certificate Master component. You must set this to *true* to use Certificate Master. Only Certificate Master is allowed to submit requests via this endpoint. ## AppConfig:DirectCSRValidation:DefaultEkus *Linux: AppConfig\_\_DirectCSRValidation\_\_DefaultEkus* **Value:** ClientAuthentication (or other EKUs) **Description:** This setting defines the default EKUs to be used for CSR signing when the CSR does not specify any. If the CSR includes its own EKU(s), this setting will be ignored. Multiple EKUs can be specified, separated by commas. ## AppConfig:DirectCSRValidation:ValidityPeriodDays *Linux: AppConfig\_\_DirectCSRValidation\_\_ValidityPeriodDays* **Value:** Positive *Integer* **Description:** This setting further reduces the global ValidityPeriodDays for the CSR endpoint. For example, you may define a value like 365 days here and set the global AppConfig:ValidityPeriodDays to 730. Then, certificates issued through Certificate Master will have one year validity, while certificates issued through other endpoints may be valid up to two years. Usually, though, you will not configure anything here and instead reduce the validity for other endpoints, because server certificates from internal PKIs usually have a longer validity then client certificates. # CRL ## How-to guide {% content-ref url="/pages/e8BwMM8UxsW2rCH3NnWd" %} [Enabling CRL](/certificate-management/manage-certificates/enabling-crl) {% endcontent-ref %} {% hint style="info" %} These settings should only be applied to the SCEPman App Service, not the Certificate Master. Please refer to [SCEPman Settings](/scepman-configuration/application-settings). {% endhint %} For a general comparison of techniques to control certificate validity, have a look into [our blog article](https://www.glueckkanja.com/blog/products/2023/05/certificate-revocation-en/). ## AppConfig:CRL:RequestToken *Linux: AppConfig\_\_CRL\_\_RequestToken* {% hint style="info" %} Applicable to version 2.3 and above {% endhint %} **Value:** A custom secret string consisting of alphanumerical characters and dashes **Description:** If you set this value to anything that is not an empty string, you can download a Certificate Revocation List (CRL) from SCEPman. The URL of the CRL is , where scepman.contoso.de is the domain of your SCEPman instance and {RequestToken} is the token configured here. The CRL currently does not contain all revoked certificates. Thus, attackers possessing a revoked certificate who gain access to the CRL might use it to try and convince a party that their revoked certificate is actually not revoked, because it is not in the list. Therefore, you should treat the RequestToken as a secret and generally only enable this feature if you require it. You should use the CRL only where it is not possible to use the superior OCSP. Keep in mind that network equipment like proxies might log the URL of the CRL. ## AppConfig:CRL:Source *Linux: AppConfig\_\_CRL\_\_Source* {% hint style="info" %} Applicable to version 2.4 and above {% endhint %} **Value:** *None* (default) or *Storage* **Description:** If you set this value to *None*, the generated CRL will contain no revoked certificates at all. If you set this value to *Storage*, the CRL will contain all manually revoked certificates that are stored in the Azure Storage. Certificates that are automatically revoked via OCSP will not be included in the CRL. For example, if you disable a device, the device's certificate will be automatically revoked via OCSP. However, the certificate will not be included in the CRL. ## AppConfig:CRL:AddCdp *Linux: AppConfig\_\_CRL\_\_AddCdp* {% hint style="info" %} Applicable to version 2.10 and above {% endhint %} **Value:** *false* (default) or *true* **Description:** If you set this value to *true*, SCEPman adds a CRL Distribution Point (CDP) extension to issued certificates, which contains the URL from where to download the current CRL from SCEPman. ## AppConfig:CRL:ValidityDays *Linux: AppConfig\_\_CRL\_\_ValidityDays* **Value:** *Floating Point Number* **Description:** The number of days that an issued CRL is valid. If nothing is configured, CRLs will be valid for **0.1 days** = 2.4 hours (SCEPman 2.4 and newer) or **30 days** (SCEPman 2.3). # Dependencies (Azure Services) # Azure KeyVault {% hint style="info" %} These settings should only be applied to the SCEPman App Service, not the Certificate Master. Please refer to [SCEPman Settings](/scepman-configuration/application-settings). {% endhint %} ## AppConfig:KeyVaultConfig:RootCertificateConfig:AddExtendedKeyUsage *Linux: AppConfig\_\_KeyVaultConfig\_\_RootCertificateConfig\_\_AddExtendedKeyUsage* **Value:** *true* or *false* **Description:** This setting determines whether SCEPman generates its CA certificates with an Extended Key Usage extension. The extension is not required by the standards, but Cisco ISE sometimes requires it to make OCSP work. **True** (default for 1.9 and above): SCEPman adds an Extended Key Usage extension to newly generated CA certificates. **False** (default for 1.8 and before): SCEPman generates a CA certificate without Extended Key Usage extension. ## AppConfig:KeyVaultConfig:RootCertificateConfig:DaysExpiresIn *Linux: AppConfig\_\_KeyVaultConfig\_\_RootCertificateConfig\_\_DaysExpiresIn* The validity of the generated Root CA certificate in days. Defaults to 3650, i.e. about ten years. We recommend to not reduce this value, as this increases availability risks, with no security advantage -- stopping the distribution of the Root CA certificate is easy and much faster than waiting for the certificate expiration. {% hint style="danger" %} Changes can harm your service! {% endhint %} ## AppConfig:KeyVaultConfig:RootCertificateConfig:KeySize *Linux: AppConfig\_\_KeyVaultConfig\_\_RootCertificateConfig\_\_KeySize* The length of the Root CA key in bits. New installations set this to 4096. If you remove the setting, it will default to 2048. It only applies when generating a new Root CA certificate, though. {% hint style="danger" %} Changes can harm your service! {% endhint %} ## AppConfig:KeyVaultConfig:RootCertificateConfig:KeyType *Linux: AppConfig\_\_KeyVaultConfig\_\_RootCertificateConfig\_\_KeyType* The type of key created for the Root CA. *RSA* is a software-protected RSA key; *RSA-HSM* is HSM-protected. If you want to use an ECC key, please contact the SCEPman support for further instructions. {% hint style="danger" %} Changes can harm your service! {% endhint %} ## AppConfig:KeyVaultConfig:KeyVaultURL *Linux: AppConfig\_\_KeyVaultConfig\_\_KeyVaultURL* The Azure Key Vault URL. This setting is automatically configured during the setup. This setting MUST be in the configuration of your App Service. It is NOT possible to define this setting as a Secret in Azure Key Vault! {% hint style="danger" %} Changes can harm your service! {% endhint %} ## AppConfig:KeyVaultConfig:RootCertificateConfig:CertificateName *Linux: AppConfig\_\_KeyVaultConfig\_\_RootCertificateConfig\_\_CertificateName* The Root Certificate Name. This setting is automatically configured during the setup. The name does not appear in the certificate itself and is only a reference to the CA certificate within Azure Key Vault. As it is part of the URL, there are name restrictions, like limitations to alphanumeric characters, numbers, and dashes. {% hint style="danger" %} Changes can harm your service! {% endhint %} ## AppConfig:KeyVaultConfig:RootCertificateConfig:Subject *Linux: AppConfig\_\_KeyVaultConfig\_\_RootCertificateConfig\_\_Subject* The Root Certificate Subject. This setting is automatically configured during the setup. It is used only as input at the time of CA certificate creation and will not be used anymore once a CA certificate exists. {% hint style="danger" %} Changes can harm your service! {% endhint %} # Logging {% hint style="info" %} These settings should only be applied to the SCEPman App Service, not the Certificate Master. Please refer to [SCEPman Settings](/scepman-configuration/application-settings). Applicable to version 2.4 and above {% endhint %} ## AppConfig:LoggingConfig:DataCollectionEndpointUri *Linux: AppConfig\_\_LoggingConfig\_\_*DataCollectionEndpointUri {% hint style="info" %} Logging via DCE is possible in version 3.0 and above {% endhint %} **Value:** Uri **Description:** The data collection endpoint Uri is the target SCEPman sends its logs to. This utilizes the default DCE of the Data Collection Rule that is created automatically in a standard deployment. ## AppConfig:LoggingConfig:RuleId *Linux: AppConfig\_\_LoggingConfig\_\_*RuleId {% hint style="info" %} Logging via DCE is possible in version 3.0 and above {% endhint %} **Value:** String **Description:** This is the unique identifier of the Data Collection Rule to be used by SCEPman. ## AppConfig:LoggingConfig:WorkspaceId *Linux: AppConfig\_\_LoggingConfig\_\_WorkspaceId* **Value:** Guid **Description:** The WorkspaceID of your Log Analytics Workspace (shown in the Overview of the workspace). This is a required setting if you want to use Azure Monitor, together with SharedKey. ## AppConfig:LoggingConfig:SharedKey *Linux: AppConfig\_\_LoggingConfig\_\_SharedKey* **Value:** String **Description:** Use one of the two keys for the Log Analytics Workspace. They are displayed if you access your SCEPman Log Analytics Workspace and navigate to Settings/Agents, where you can unfold the "Log Analytics agent instructions" section. Use either the Primary or the Secondary key. This is a required setting if you want to use Azure Monitor, together with WorkspaceId. ## AppConfig:LoggingConfig:AzureOfferingDomain *Linux: AppConfig\_\_LoggingConfig\_\_AzureOfferingDomain* **Value:** String **Description:** If the workspace is not in the Global Azure Cloud, you can configure the offering domain here. The default is 'azure.com'. {% hint style="danger" %} Changes can harm your service! {% endhint %} ## AppConfig:LoggingConfig:LogLevel *Linux: AppConfig\_\_LoggingConfig\_\_LogLevel* **Value:** *Trace*, *Debug*, *Info*, *Warn*, *Error*, or *Fatal* **Description:** The minimum log level to be logged. The default is 'Info'. Only log entries with a log level equal or higher than the configured log level will be logged. Note that if you configure this setting to 'Trace' or 'Debug', log output might contain personal data like UPNs or IP addresses of users. If you want to avoid personal data in the log output, you should configure this setting to 'Info' or higher. ## AppConfig:LoggingConfig:AzureEventHubConnectionString *Linux: AppConfig\_\_LoggingConfig\_\_AzureEventHubConnectionString* {% hint style="info" %} Logging to Azure Event Hub is possible in version 2.5 and above {% endhint %} **Value:** String **Description:** The connection string to your Azure Event Hub. If you want to use Azure Event Hub, you must either configure this setting or [AppConfig:LoggingConfig:AzureEventHubServiceUri](#appconfig-loggingconfig-azureeventhubserviceuri). If you use AzureEventHubConnectionString, it must include the authentication information. ## AppConfig:LoggingConfig:AzureEventHubName *Linux: AppConfig\_\_LoggingConfig\_\_AzureEventHubName* {% hint style="info" %} Logging to Azure Event Hub is possible in version 2.5 and above {% endhint %} **Value:** String **Description:** The name of your Azure Event Hub. This is a required setting if you want to use Azure Event Hub. ## AppConfig:LoggingConfig:AzureEventHubPartitionKey *Linux: AppConfig\_\_LoggingConfig\_\_AzureEventHubPartitionKey* {% hint style="info" %} Logging to Azure Event Hub is possible in version 2.5 and above {% endhint %} **Value:** String **Description:** The partition key of your Azure Event Hub. Setting this is optional. If you don't set this, this defaults to '0'. ## AppConfig:LoggingConfig:AzureEventHubServiceUri *Linux: AppConfig\_\_LoggingConfig\_\_AzureEventHubServiceUri* {% hint style="info" %} Logging to Azure Event Hub with Managed Identity is possible in version 2.8 and above {% endhint %} **Value:** String Description: The Service URI of the Azure Event Hub. If you want to use Azure Event Hub, you must either configure this setting or [AppConfig:LoggingConfig:AzureEventHubConnectionString](#appconfig-loggingconfig-azureeventhubconnectionstring). If you use AzureEventHubServiceUri, SCEPman/Certificate Master will authenticate with its Managed Identity to the Azure Event Hub Service. # Microsoft Entra ID (Azure AD) {% hint style="info" %} These settings should only be applied to the SCEPman App Service, not the Certificate Master. Please refer to [SCEPman Settings](/scepman-configuration/application-settings). {% endhint %} ## AppConfig:AuthConfig:ApplicationId *Linux: AppConfig\_\_AuthConfig\_\_ApplicationId* The [Application (client) ID](/scepman-deployment/permissions/azure-app-registration#basic-app-registration-application-id) from your Microsoft Entra ID (Azure AD) App registration. This setting is configured during the setup. {% hint style="warning" %} Please do not mix this up with the "Client Secret ID". We need the "Application (client) ID", here. {% endhint %} {% hint style="danger" %} Changes can harm your service! {% endhint %} ## AppConfig:AuthConfig:ApplicationKey *Linux: AppConfig\_\_AuthConfig\_\_ApplicationKey* The [Application Key (client secret **value**)](/scepman-deployment/permissions/azure-app-registration#azure-app-registration-client-secret) from your Microsoft Entra ID (Azure AD) App registration. This setting is configured during the setup of a SCEPman 1.x version. SCEPman 2.x usually does not use this setting and instead relies on [Managed Identity authentication](/scepman-deployment/permissions/post-installation-config). {% hint style="warning" %} Please do not mix this up with the "Client Secret **ID**". We need the "Client Secret **Value**", here. {% endhint %} {% hint style="danger" %} Changes can harm your service! {% endhint %} ## AppConfig:AuthConfig:TenantId *Linux: AppConfig\_\_AuthConfig\_\_TenantId* The Microsoft Entra ID (Azure AD) Tenant ID. This setting is automatically configured during the setup. {% hint style="danger" %} Changes can harm your service! {% endhint %} ## AppConfig:AuthConfig:HomeTenantId *Linux: AppConfig\_\_AuthConfig\_\_HomeTenantId* When running SCEPman in a different tenant than Intune, this specifies the Id of the tenant hosting the SCEPman Azure resource, while [AppConfig:AuthConfig:TenantId](#appconfig-authconfig-tenantid) specifies the tenant of Intune. In this case, you cannot use the more convenient [authentication based on Managed Identities](/scepman-deployment/permissions/post-installation-config), but must use authentication using [an Azure App Registration and a Client Secret](/scepman-deployment/permissions/azure-app-registration). {% hint style="danger" %} Changes can harm your service! {% endhint %} ## AppConfig:AuthConfig:HomeApplicationId *Linux: AppConfig\_\_AuthConfig\_\_HomeApplicationId* This setting is only used for situations where SCEPman runs in a different tenant than Intune. The HomeApplicationId specifies the application ID of your `scepman-api` app registration in the tenant where the SCEPman and Certificate Master App Services run. [AppConfig:AuthConfig:ApplicationId](#appconfig-authconfig-applicationid) and [AppConfig:AuthConfig:ApplicationKey](#appconfig-authconfig-applicationkey) specify the application ID and Client Secret Value, respectively, of the app registration in the tenant where Intune runs. {% hint style="warning" %} Please do not mix this up with the "Client Secret ID". We need the "Application (client) ID", here. {% endhint %} {% hint style="danger" %} Changes can harm your service! {% endhint %} ## AppConfig:AuthConfig:ManagedIdentityEnabledOnUnixTime *Linux: AppConfig\_\_AuthConfig\_\_ManagedIdentityEnabledOnUnixTime* The time as Unix epoch when the required permissions to the Managed Identity were granted. SCEPman acquires a token using the Managed Identity only after a short delay (60 seconds in SCEPman 2.0) after this time, because only then do the roles in the token reflect the correct permissions added by the CMDlet. The tokens are cached [for 24 hours with no way to force refresh the cache](https://docs.microsoft.com/en-us/azure/app-service/overview-managed-identity?tabs=portal%2Cdotnet#configure-target-resource), so if you added a permission after SCEPman has acquired a token, you need to wait up to 24 hours until SCEPman can use this new permission. {% hint style="danger" %} Changes can harm your service! {% endhint %} # National Cloud Platforms {% hint style="info" %} These settings should only be applied to the SCEPman App Service, not the Certificate Master. Please refer to [SCEPman Settings](/scepman-configuration/application-settings). {% endhint %} If you want to run SCEPman in a government / national cloud environment like GCC High, GCC DoD, or 21ViaNet, you have to alter some settings. If you run SCEPman in the standard Azure environment, just leave these settings empty to use the defaults. The following settings provide you the means to configure cloud-specific URLs and values if you are not using the standard Azure environment. See also the [Logging configuration](/scepman-configuration/application-settings/logging#appconfig-loggingconfig-azureofferingdomain) if you want to log to a Log Analytics Workspace in a different cloud environment. ## AppConfig:AzureCloudConfig:AzureADEndpoint *Linux: AppConfig\_\_AzureCloudConfig\_\_AzureADEndpoint* **Value:** URL as string **Description:**\ This is the AAD logon URL. It defaults to `https://login.microsoftonline.com`. For GCC High, use `https://login.microsoftonline.us`. For 21Vianet, use `https://login.partner.microsoftonline.cn`. ## AppConfig:AzureCloudConfig:AzureADGraphEndpoint *Linux: AppConfig\_\_AzureCloudConfig\_\_AzureADGraphEndpoint* **Value:** URL as string **Description:**\ This is the AAD Graph URL. It defaults to `https://graph.windows.net/`. You may not need to configure this if you let SCEPman use only Microsoft Graph. ## AppConfig:AzureCloudConfig:AzureADGraphVersion *Linux: AppConfig\_\_AzureCloudConfig\_\_AzureADGraphVersion* **Value:** string **Description:**\ The version of AAD Graph to use. It defaults to `1.6`. ## AppConfig:AzureCloudConfig:MSGraphEndpoint *Linux: AppConfig\_\_AzureCloudConfig\_\_MSGraphEndpoint* **Value:** URL as string **Description:**\ The URL of Microsoft Graph. It defaults to `https://graph.microsoft.com`. For GCC High, use `https://graph.microsoft.us`. For GCC DoD, use `https://dod-graph.microsoft.us`. For 21Vianet, use `https://microsoftgraph.chinacloudapi.cn`. ## AppConfig:AzureCloudConfig:KeyVaultEndpoint *Linux: AppConfig\_\_AzureCloudConfig\_\_KeyVaultEndpoint* **Value:** URL as string **Description:**\ The URL of Azure Key Vaults. It defaults to `https://vault.azure.net`. For GCC High, use `https://vault.usgovcloudapi.net`. For 21Vianet, use `https://vault.azure.cn`. ## AppConfig:AzureCloudConfig:ManagementEndpoint *Linux: AppConfig\_\_AzureCloudConfig\_\_ManagementEndpoint* **Value:** URL as string **Description:**\ The URL of the Intune API. It defaults to `https://api.manage.microsoft.com`. For GCC High, use `https://api.manage.microsoft.us`. ## AppConfig:AzureCloudConfig:IntuneAppId *Linux: AppConfig\_\_AzureCloudConfig\_\_IntuneAppId* **Value:** Guid as string **Description:**\ The well-known Intune App ID. It defaults to `0000000a-0000-0000-c000-000000000000`. # Enrollment REST API {% hint style="warning" %} SCEPman Enterprise Edition only Applicable to version 2.3.689 and above {% endhint %} {% hint style="info" %} These settings should only be applied to the SCEPman App Service, not the Certificate Master. Please refer to [SCEPman Settings](/scepman-configuration/application-settings). {% endhint %} ## AppConfig:DbCSRValidation:Enabled *Linux: AppConfig\_\_DbCSRValidation\_\_Enabled* **Value:** *true* or *false* (default) **Description:** This is a REST API endpoint that custom scripts and processes can use. See [our article on how to use the REST API](/certificate-management/api-certificates) for details. ## AppConfig:DbCSRValidation:ValidityPeriodDays *Linux: AppConfig\_\_DbCSRValidation\_\_ValidityPeriodDays* **Value:** Positive Integer **Description:** This setting further reduces the global ValidityPeriodDays for the REST API endpoint. For example, you may define a value like 365 days here and set the global [AppConfig:ValidityPeriodDays](#appconfig-dbcsrvalidation-validityperioddays) to 730. Then, certificates issued through the API will have one year validity, while certificates issued through other endpoints may be valid up to two years. Additionally, you can include an extension in your PKCS#10 requests to enroll certificates with a specific individual validity that is lower than the one configured here. ## AppConfig:DbCSRValidation:AllowRenewals *Linux: AppConfig\_\_DbCSRValidation\_\_AllowRenewals* **Value:** *true* or *false* (default) **Description:** This allows using the EST "simplereenroll" endpoint, enabling [certificate renewal using mTLS](https://docs.scepman.com/certificate-deployment/api-certificates/api-enrollment#id-2.-app-service-settings). It works only for certificate types added to [AppConfig:DbCSRValidation:ReenrollmentAllowedCertificateTypes.](#appconfig-dbcsrvalidation-reenrollmentallowedcertificatetypes) ## AppConfig:DbCSRValidation:ReenrollmentAllowedCertificateTypes *Linux: AppConfig\_\_DbCSRValidation\_\_ReenrollmentAllowedCertificateTypes* **Value:** Comma-separated list of certificate types from this list: * DomainController * Static * IntuneUser * IntuneDevice * JamfUser * JamfUserWithDevice * JamfUserWithComputer * JamfDevice * JamfComputer **Description:** You can use the simplereenroll endpoint for certificates of the types specified in this setting. If you do not specifiy any value, it defaults to no types, i.e. you cannot use the simplereenroll endpoint. For example, if you wanted to renew certificates issued manually through Certificate Master, you would specify `Static`. If you also want to renew Domain Controller certificates, you would specify `DomainController,Static`. # Active Directory {% hint style="warning" %} SCEPman Enterprise Edition only Applicable to version 3.0 and above {% endhint %} {% hint style="info" %} These settings should only be applied to the SCEPman App Service, not the Certificate Master. Please refer to [SCEPman Settings](/scepman-configuration/application-settings). {% endhint %} ## General Settings The following settings affect the behavior of the Active Directory endpoint in general. {% content-ref url="/pages/fxYRQ8tdRF9SK784z4ds" %} [General](/scepman-configuration/application-settings/active-directory/general) {% endcontent-ref %} ## Certificate Templates Aside from the general settings of the endpoint, the certificate templates can be configured independently. The format of those variable names follow the scheme `AppConfig:ActiveDirectory:[Template]:[Setting]` where `[Template]` is to be replaced with User, Computer or DC and `[Setting]` is to be replaced with the respective setting name. You can find the configuration options for the certificate templates in the following pages. {% content-ref url="/pages/zaZtGd4iOGTIJ1kmZY40" %} [User Template](/scepman-configuration/application-settings/active-directory/user-template) {% endcontent-ref %} {% content-ref url="/pages/nhvwYEAx3TR1DcQiCFn3" %} [Computer Template](/scepman-configuration/application-settings/active-directory/computer-template) {% endcontent-ref %} {% content-ref url="/pages/KJ8oFbXhys2rU3EdUiHa" %} [DC Template](/scepman-configuration/application-settings/active-directory/dc-template) {% endcontent-ref %} # General ## AppConfig:ActiveDirectory:Keytab *Linux: AppConfig\_\_ActiveDirectory\_\_Keytab* **Value:** Output from New-SCEPmanADPrincipal **Description:** The encoded Kerberos keytab of the service principal created by New-SCEPmanADPrincipal. The keytab is encrypted using the public key of SCEPmans CA certificate which allows for a secure transfer of this information. Technically, the encryption is a PKCS#7 encrypted to the CA certificate's private key. While the keytab itself is sensitive information, this encypted value can only be decrypted by the CA certificate and SCEPman holds the keytab only in memory, so it requires no special security precautions like configuring this value in a Key Vault secret instead of an environment variable. ## AppConfig:ActiveDirectory:GroupFilter *Linux: AppConfig\_\_ActiveDirectory\_\_GroupFilter* **Value:** Comma-separated list of AD groups specified by their SID **Description:** This setting allows to limit the usage of the endpoint to members of the specified Active Directory groups. ## AppConfig:ActiveDirectory:RenewalThresholdPercentage *Linux: AppConfig\_\_ActiveDirectory\_\_RenewalThresholdPercentage* **Value:** Floating point number of the percentage. Default is 0.2 (20%) **Description:** If the remaining validity of a certificate falls below this percentage of the total certificate validity, a renewal should be triggered on the client side. ## AppConfig:ActiveDirectory:BaseUrl *Linux: AppConfig\_\_ActiveDirectory\_\_BaseUrl* **Value:** **Description:** This defines the base URL of the Active Directory endpoint that will be displayed on the SCEPman homepage and will be returned in the policies requested by your clients. Defaults to AppConfig:BaseUrl {% hint style="info" %} This setting should only be set if you require your Active Directory endpoint to be accessed at a different URL than SCEPman in general. {% endhint %} # User Template ## AppConfig:ActiveDirectory:page.vars.cert\_template:Enabled *Linux: AppConfig\_\_ActiveDirectory\_\_*page.vars.cert\_template*\_\_Enabled* **Value:** *true* or *false* (default) **Description:** This setting enables the certificate template `SCEPmanUser` ## AppConfig:ActiveDirectory:page.vars.cert\_template:TemplateName *Linux: AppConfig\_\_ActiveDirectory\_\_*page.vars.cert\_template*\_\_TemplateName* **Value:** Certificate template name **Description:** This setting allows you to choose a custom template name for this certificate template. It is displayed when you manually enroll a certificate of that template. For maximum compatibility, choose a name witho only alphanumeric characters and no blanks. ## AppConfig:ActiveDirectory:page.vars.cert\_template:GroupFilter *Linux: AppConfig\_\_ActiveDirectory\_\_*page.vars.cert\_template*\_\_GroupFilter* **Value:** Comma-separated list of AD groups specified by their SID **Description:** This setting limits which Active Directory group members are allowed to enroll certificates for this certificate template. If configured, it overrides the general setting [AppConfig:ActiveDirectory:GroupFilter](#appconfig-activedirectory-groupfilter). ## AppConfig:ActiveDirectory:page.vars.cert\_template:Ksps *Linux: AppConfig\_\_ActiveDirectory\_\_*page.vars.cert\_template*\_\_Ksps* **Value:** Semicolon-separated list of CSPs/KSPs allowed for key generation **Description:** You can define the key storage providers in which the certificates private key might be created in. If no value is specified, all KSPs are allowed to be used, and the client decides which KSP suites best. Valid values include: * **Microsoft Platform Crypto Provider** - Stores the private key in the device's TPM. * **Microsoft Passport Key Storage Provider** * **Microsoft Software Key Storage Provider** - Stores the private key on the hard drive, secured with the machine key. * **Microsoft Smart Card Key Storage Provider** - Stores the private key on a smart card. # Computer Template ## AppConfig:ActiveDirectory:page.vars.cert\_template:Enabled *Linux: AppConfig\_\_ActiveDirectory\_\_*page.vars.cert\_template*\_\_Enabled* **Value:** *true* or *false* (default) **Description:** This setting enables the certificate template `SCEPmanDevice` ## AppConfig:ActiveDirectory:page.vars.cert\_template:TemplateName *Linux: AppConfig\_\_ActiveDirectory\_\_*page.vars.cert\_template*\_\_TemplateName* **Value:** Certificate template name **Description:** This setting allows you to choose a custom template name for this certificate template. It is displayed when you manually enroll a certificate of that template. For maximum compatibility, choose a name witho only alphanumeric characters and no blanks. ## AppConfig:ActiveDirectory:page.vars.cert\_template:GroupFilter *Linux: AppConfig\_\_ActiveDirectory\_\_*page.vars.cert\_template*\_\_GroupFilter* **Value:** Comma-separated list of AD groups specified by their SID **Description:** This setting limits which Active Directory group members are allowed to enroll certificates for this certificate template. If configured, it overrides the general setting [AppConfig:ActiveDirectory:GroupFilter](#appconfig-activedirectory-groupfilter). ## AppConfig:ActiveDirectory:page.vars.cert\_template:Ksps *Linux: AppConfig\_\_ActiveDirectory\_\_*page.vars.cert\_template*\_\_Ksps* **Value:** Semicolon-separated list of CSPs/KSPs allowed for key generation **Description:** You can define the key storage providers in which the certificates private key might be created in. If no value is specified, all KSPs are allowed to be used, and the client decides which KSP suites best. Valid values include: * **Microsoft Platform Crypto Provider** - Stores the private key in the device's TPM. * **Microsoft Passport Key Storage Provider** * **Microsoft Software Key Storage Provider** - Stores the private key on the hard drive, secured with the machine key. * **Microsoft Smart Card Key Storage Provider** - Stores the private key on a smart card. # DC Template ## AppConfig:ActiveDirectory:page.vars.cert\_template:Enabled *Linux: AppConfig\_\_ActiveDirectory\_\_*page.vars.cert\_template*\_\_Enabled* **Value:** *true* or *false* (default) **Description:** This setting enables the certificate template `KerberosAuthentication` targeted at Domain Controllers. ## AppConfig:ActiveDirectory:page.vars.cert\_template:TemplateName *Linux: AppConfig\_\_ActiveDirectory\_\_*page.vars.cert\_template*\_\_TemplateName* **Value:** Certificate template name **Description:** This setting allows you to choose a custom template name for this certificate template. It is displayed when you manually enroll a certificate of that template. For maximum compatibility, choose a name witho only alphanumeric characters and no blanks. ## AppConfig:ActiveDirectory:page.vars.cert\_template:GroupFilter *Linux: AppConfig\_\_ActiveDirectory\_\_*page.vars.cert\_template*\_\_GroupFilter* **Value:** Comma-separated list of AD groups specified by their SID **Description:** This setting limits which Active Directory group members are allowed to enroll certificates for this certificate template. If configured, it overrides the general setting [AppConfig:ActiveDirectory:GroupFilter](#appconfig-activedirectory-groupfilter). ## AppConfig:ActiveDirectory:page.vars.cert\_template:Ksps *Linux: AppConfig\_\_ActiveDirectory\_\_*page.vars.cert\_template*\_\_Ksps* **Value:** Semicolon-separated list of CSPs/KSPs allowed for key generation **Description:** You can define the key storage providers in which the certificates private key might be created in. If no value is specified, all KSPs are allowed to be used, and the client decides which KSP suites best. Valid values include: * **Microsoft Platform Crypto Provider** - Stores the private key in the device's TPM. * **Microsoft Passport Key Storage Provider** * **Microsoft Software Key Storage Provider** - Stores the private key on the hard drive, secured with the machine key. * **Microsoft Smart Card Key Storage Provider** - Stores the private key on a smart card. # RDP Template ## AppConfig:ActiveDirectory:page.vars.cert\_template:Enabled *Linux: AppConfig\_\_ActiveDirectory\_\_*page.vars.cert\_template*\_\_Enabled* **Value:** *true* or *false* (default) **Description:** This setting enables the certificate template `SCEPmanRdpServer` ## AppConfig:ActiveDirectory:page.vars.cert\_template:TemplateName *Linux: AppConfig\_\_ActiveDirectory\_\_*page.vars.cert\_template*\_\_TemplateName* **Value:** Certificate template name **Description:** This setting allows you to choose a custom template name for this certificate template. It is displayed when you manually enroll a certificate of that template. For maximum compatibility, choose a name witho only alphanumeric characters and no blanks. ## AppConfig:ActiveDirectory:page.vars.cert\_template:GroupFilter *Linux: AppConfig\_\_ActiveDirectory\_\_*page.vars.cert\_template*\_\_GroupFilter* **Value:** Comma-separated list of AD groups specified by their SID **Description:** This setting limits which Active Directory group members are allowed to enroll certificates for this certificate template. If configured, it overrides the general setting [AppConfig:ActiveDirectory:GroupFilter](#appconfig-activedirectory-groupfilter). ## AppConfig:ActiveDirectory:page.vars.cert\_template:Ksps *Linux: AppConfig\_\_ActiveDirectory\_\_*page.vars.cert\_template*\_\_Ksps* **Value:** Semicolon-separated list of CSPs/KSPs allowed for key generation **Description:** You can define the key storage providers in which the certificates private key might be created in. If no value is specified, all KSPs are allowed to be used, and the client decides which KSP suites best. Valid values include: * **Microsoft Platform Crypto Provider** - Stores the private key in the device's TPM. * **Microsoft Passport Key Storage Provider** * **Microsoft Software Key Storage Provider** - Stores the private key on the hard drive, secured with the machine key. * **Microsoft Smart Card Key Storage Provider** - Stores the private key on a smart card. # OCSP {% hint style="info" %} These settings should only be applied to the SCEPman App Service, not the Certificate Master. Please refer to [SCEPman Settings](/scepman-configuration/application-settings). {% endhint %} ## AppConfig:OCSP:UseAuthorizedResponder *Linux: AppConfig\_\_OCSP\_\_UseAuthorizedResponder* {% hint style="info" %} Applicable to version 2.9 and above {% endhint %} **Value:** *true* (default since 3.1) or *false* **Description:** If this is set to *false*, the CA certificate will sign OCSP Responses. It is the simpler approach. If it is set to *true* or not set, SCEPman will dynamically issue an [Authorized Responder certificate](https://datatracker.ietf.org/doc/html/rfc6960#section-4.2.2.2) to sign OCSP Responses. This Authorized Responder has a short validity (see AuthorizedResponderValidityHours below) and a new certificate will be issued automatically whenever needed. The certificate along with its private key will be held in memory only, so there is no need for SCEPman administrators to manage the Authorized Responders certificate. This reduces the dependency on Key Vault, improving response times and availability, and is one method to avoid the [Key Vault throttling limit](https://learn.microsoft.com/en-us/azure/key-vault/general/service-limits) that might otherwise affect larger SCEPman installation (> \~50k users). ## AppConfig:OCSP:AuthorizedResponderValidityHours *Linux: AppConfig\_\_OCSP\_\_AuthorizedResponderValidityHours* {% hint style="info" %} Applicable to version 2.9 and above {% endhint %} **Value:** Floating point value (*24.0* as default) **Description:** This is only applicable if you enable the Authorized OCSP Responder by setting UseAuthorizedResponder to *true*. This value determines the expiration date of the Authorized OCSP Responder certificate. By default, it expires one day after issuance. Note that due to the setting [AppConfig:ValidityClockSkewMinutes](/scepman-configuration/application-settings/certificates#appconfig-validityclockskewminutes), the issuance date is backdated and therefore the actual validity is usually two days (one into the past, one into the future). ## AppConfig:OCSP:CacheTimeOutSecondsIfDeviceExists *Linux: AppConfig\_\_OCSP\_\_CacheTimeOutSecondsIfDeviceExists* **Value:** Integer (*600* as default) **Description:** This is the validity in seconds of OCSP Responses for valid certificates. Technically, an OCSP Response can be re-used within its validity if no [OCSP Nonce](https://datatracker.ietf.org/doc/html/rfc6960#section-4.4.1) is used, e.g. by a proxy or an internal SCEPman cache. On some systems like Windows, the OCSP Response is stored in a client cache for its validity period, and when checking for a certificate's validity, a new OCSP Request will only be send when there is no valid OCSP Response already in the cache. Therefore, the value determines the maximum delay between a certificate revocation and when a system caching an OCSP response actually treats a certificate as revoked. A lower number might increase the number of OCSP requests and therefore the load on SCEPman. ## AppConfig:OCSP:CacheTimeOutSecondsIfDeviceIsDisabled *Linux: AppConfig\_\_OCSP\_\_CacheTimeOutSecondsIfDeviceIsDisabled* **Value:** Integer (*300* as default) **Description:** This is the validity in seconds of OCSP Responses for disabled certificates, i.e. that have the *On Hold* revocation status. These certificates are revoked, but could become valid again. Examples are device certificates for devices that are disabled in Entra Id, or user certificates for [users with a high user risk score](/scepman-configuration/application-settings/scep-endpoints/intune-validation#appconfig-intunevalidation-userriskcheck). The setting has no influence on permanently revoked certificates. Their OCSP response have long validities, as their revocation status cannot change anymore. Therefore, the value determines the maximum delay between restoring a certificate's validity (e.g. by enabling a device in Entra ID) and effectively cancelling the revocation on a system caching an OCSP response. # SCEP Endpoints {% content-ref url="/pages/fibVgymAScyyESpOQXHW" %} [DC Validation](/scepman-configuration/application-settings/scep-endpoints/dc-validation) {% endcontent-ref %} {% content-ref url="/pages/K9x9W7G0DuvIh59l33Rn" %} [Intune Validation](/scepman-configuration/application-settings/scep-endpoints/intune-validation) {% endcontent-ref %} {% content-ref url="/pages/uRi78Qw4ESDvvapiVrig" %} [Jamf Validation](/scepman-configuration/application-settings/scep-endpoints/jamf-validation) {% endcontent-ref %} {% content-ref url="/pages/jP0zmIFEXUW0KhUyVqgf" %} [Static Validation](/scepman-configuration/application-settings/scep-endpoints/static-validation) {% endcontent-ref %} {% content-ref url="/pages/Vp13S2ddpmTODyV9mr7z" %} [Static-AAD Validation](/scepman-configuration/application-settings/scep-endpoints/staticaad-validation) {% endcontent-ref %} # DC Validation {% hint style="warning" %} SCEPman Enterprise Edition only {% endhint %} {% hint style="info" %} These settings should only be applied to the SCEPman App Service, not the Certificate Master. Please refer to [SCEPman Settings](/scepman-configuration/application-settings). {% endhint %} ## AppConfig:DCValidation:Enabled *Linux: AppConfig\_\_DCValidation\_\_Enabled* **Value:** *true* or *false* (default) **Description:** This setting helps you to request Kerberos server certificates for your on-premises Domain Controllers. See [Domain Controller Certificates](/certificate-management/domain-controller-certificates) for details. * **True**: SCEPman listens at the additional SCEP server endpoint with the path `/dc`. Use in conjunction with [AppConfig:DCValidation:RequestPassword](#appconfig-dcvalidation-requestpassword). * **False** (default): SCEPman does not issue certificates for Domain Controllers. ## AppConfig:DCValidation:RequestPassword *Linux: AppConfig\_\_DCValidation\_\_RequestPassword* **Value:** *String* **Description:** A challenge password that the Domain Controllers must include in every SCEP request to acquire a certificate. Only used if AppConfig:DCValidation:Enabled is set to *true*. We recommend defining this setting as Secret in Azure Key Vault. The Secret must have the name *AppConfig--DCValidation--RequestPassword*. ## AppConfig:DCValidation:ValidityPeriodDays *Linux: AppConfig\_\_DCValidation\_\_ValidityPeriodDays* **Value:** Positive *Integer* **Description:** This setting further reduces the global ValidityPeriodDays for the Domain Controller endpoint. For example, you may define a low value like 10 days here and reduce the validity of Domain Controller certificates, while still having a long validity for your client certificates. ## AppConfig:DCValidation:EnableCertificateStorage *Linux: AppConfig\_\_DCValidation\_\_EnableCertificateStorage* {% hint style="info" %} Applicable to version 2.3 and above {% endhint %} **Value:** *true* or *false* (default) **Description:** When requesting certificates via the DC endpoint, SCEPman stores those requested certificates in the Storage Account in Azure if this is set to *true*. This will make the issued certificates appear in SCEPman Certificate Master, where you can view and revoke them. If set to *false*, SCEPman will not store issued certificates and the certificates are visible only in the logs or if the SCEP client stores them somewhere. If this is not set, the behavior depends on the global setting [AppConfig:EnableCertificateStorage](/scepman-configuration/application-settings/basics#appconfig-enablecertificatestorage). # Intune Validation {% hint style="info" %} These settings should only be applied to the SCEPman App Service, not the Certificate Master. Please refer to [SCEPman Settings](/scepman-configuration/application-settings). {% endhint %} ## AppConfig:IntuneValidation:ComplianceCheck *Linux: AppConfig\_\_IntuneValidation\_\_ComplianceCheck* {% hint style="warning" %} **Experimental Setting** SCEPman Enterprise Edition only Before version 1.9, due to delayed compliance state evaluation during enrollment this feature breaks Windows Autopilot enrollment. After certificate deployment the immediately following OCSP check will return '**not valid**' during enrollment time and the Autopilot process will not succeed. With version 1.9 and above, clients receive an "Ephemeral Bootstrap Certificate" during the enrollment phase that is later replaced with a regular client certificate, as soon as the client becomes compliant. With version 2.5 and above, you can alternatively configure a grace period during which the device is always considered compliant with the setting ComplianceGracePeriodMinutes. {% endhint %} **Value:** *Always* or *Never* (default) **Description:** When SCEPman receives an OCSP request, SCEPman can optionally check the device compliance state. When set to **Always** SCEPman will query the device compliance state and the OCSP result can only be GOOD if the device is also marked as compliant in Azure AD. Setting this to **Never** will disable the compliance check. ## AppConfig:IntuneValidation:ComplianceGracePeriodMinutes *Linux: AppConfig\_\_IntuneValidation\_\_ComplianceGracePeriodMinutes* {% hint style="warning" %} SCEPman Enterprise Edition only Applicable to version 2.5 and above {% endhint %} **Value:** *Integer* (default: 0) **Description:** Immediately after enrollment, devices are often not yet compliant in Intune. This setting defines a grace period in minutes during which the device is considered compliant, even if it is not yet. If the device is not compliant after the grace period, the certificate is revoked. This prevents the problem of a Windows device that is just enrolling and needs to successfully complete the SCEP profile in order to finish Windows Autopilot enrollment, but will become compliant in Intune only some time later. The setting will check the Intune property EnrolledDateTime and start counting from that point. It is an alternative to using Ephemeral Bootstrap Certificates. If you configure any value above 0, SCEPman will never issue Ephemeral Bootstrap Certificates. This setting is only effective if [ComplianceCheck](#appconfig-intunevalidation-compliancecheck) is set to *Always*. ## AppConfig:IntuneValidation:DeviceDirectory *Linux: AppConfig\_\_IntuneValidation\_\_DeviceDirectory* **Value:** String Available options: * `AAD`\ (default for SCEPman 2.0) * `Intune` * `AADAndIntune` * `AADAndIntuneOpportunistic`\ (default for SCEPman 2.1 or newer) * `AADAndIntuneAndEndpointlist`\ (available in SCEPman 2.2 and newer) {% hint style="warning" %} If you want to change this setting in an existing deployment that was installed with a previous version of SCEPman, please run the [PowerShell configuration script](/scepman-deployment/permissions/post-installation-config#acquire-and-run-the-scepman-installation-powershell-module) again to make sure that SCEPman has the latest permissions to access the corresponding device directories. {% endhint %} **Description:** Determines where to look up devices on OCSP requests for device certificates. The corresponding directory is queried for a device matching the device ID written to the certificate's subject CN field. The certificate is valid only if the device exists. For **`AAD`**, it must also be enabled (Intune doesn't support disabling devices). If the ComplianceCheck is activated, the device must also be compliant. If nothing is configured and for SCEPman 1.9 and before, `AAD` is used. Hence, you must configure the Intune configuration profile for devices accordingly. `{{AAD_Device_ID}}` is the Entra/AAD device ID, while `{{DeviceID}}` is the Intune device ID. For **`AADAndIntune`**, both directories are queried in parallel. In this case, it is sufficient that the device exists in one of the two directories. This setting enables migrating from one setting to the other when there are still valid certificates for both types of directories. It also supports cases where you configure platforms differently. It can also be used as a workaround for iOS or Android devices that receive an Intune ID instead of an Entra ID object ID, because they are not fully Entra-joined at the time of certificate enrollment. If you have upgraded from SCEPman 1.x to SCEPman 2.x and you are still using [an App Registration for SCEPman permissions](/scepman-deployment/permissions/azure-app-registration), SCEPman lacks the permissions to query Intune for devices. Thus, you are limited to the `AAD` option. The option **`AADAndIntuneOpportunistic`** checks whether the permissions to query Intune have been granted to SCEPman. If they are there, this works like `AADAndIntune`. If they are not there, this behaves like `AAD`. The value **`AADAndIntuneAndEndpointlist`** works just like `AADAndIntune`, but additionally queries [Intune's list of issued certificates](https://endpoint.microsoft.com/#view/Microsoft_Intune_DeviceSettings/DevicesMonitorMenu/~/certificateReport). If Intune [triggered the revocation of a certificate](https://learn.microsoft.com/en-us/mem/intune/protect/remove-certificates#scep-certificates), this will make the certificate revoked in SCEPman. {% embed url="" %} SCEPman 2.0: Certificate Validation {% endembed %} ## AppConfig:IntuneValidation:RevokeCertificatesOnWipe *Linux: AppConfig\_\_IntuneValidation\_\_RevokeCertificatesOnWipe* {% hint style="info" %} Applicable to version 2.1 and above. {% endhint %} **Value:** *true* (default) or *false* **Description:** This setting extends validation of devices when using the Intune Device ID. It does not work when using the Entra/AAD Device ID. If it is enabled, SCEPman evaluates the Management State property of an Intune Device when its device certificate is validated. If the state indicates one of the following values, the certificate is revoked: * RetirePending * RetireFailed * WipePending * WipeFailed * Unhealthy * DeletePending * RetireIssued * WipeIssued Especially, this means that when an administrator triggers a Wipe or Retire for a device, the certificate will be revoked immediately. Even if the device is shutdown or offline and therefore the action cannot be performed on the device, the certificate is not valid anymore. ## AppConfig:IntuneValidation:UntoleratedUserRisks *Linux: AppConfig\_\_IntuneValidation\_\_UntoleratedUserRisks* {% hint style="warning" %} **Experimental Setting** - Applicable to version 2.2 and above. Requires permission *IdentityRiskyUser.Read.All* assigned by SCEPman PS module version 1.7 and above. SCEPman Enterprise Edition only {% endhint %} **Value:** Comma-separated list of User Risk Levels, e.g. *Low*, *Medium*, *High*. **Description:** This setting only has an effect if you set [UserRiskCheck](#appconfig-intunevalidation-userriskcheck) to *Always*. Certificates of users with risk levels in this list will be considered invalid. Example: You define `Medium,High` for this setting. A user has Risk Level *Low*. The user's certificate is valid and the certificate can be used to connect to the corporate VPN. Then, a risk event increases the User Risk Level to *Medium*. The user tries to connect to the VPN, but does not succeed, because the VPN Gateway checks the validity of the certificate in real-time and SCEPman responds that it is revoked. ## AppConfig:IntuneValidation:UserRiskCheck *Linux: AppConfig\_\_IntuneValidation\_\_UserRiskCheck* {% hint style="warning" %} **Experimental Setting** - Applicable to version 2.2 and above. Requires permission *IdentityRiskyUser.Read.All* assigned by SCEPman PS module version 1.7 and above. SCEPman Enterprise Edition only {% endhint %} **Value:** *Always* or *Never* (default) **Description:** When SCEPman receives an OCSP request for a certificate issued to an Intune user, SCEPman can optionally check the [user risk level](https://docs.microsoft.com/en-us/azure/active-directory/identity-protection/concept-identity-protection-risks#user-linked-detections). When set to **Always** SCEPman will query the user risk state and the OCSP result can only be GOOD if the user's risk is not in the list of [UntoleratedUserRisks](#appconfig-intunevalidation-untolerateduserrisks). Setting this to **Never** will disable the user risk check. ## AppConfig:IntuneValidation:WaitForSuccessNotificationResponse *Linux: AppConfig\_\_IntuneValidation\_\_WaitForSuccessNotificationResponse* **Value:** *true* (default) or *false* **Description:** After a certificate was successfully issued, SCEPman sends a notification about the certificate to Intune. Microsoft recommends to wait for the response in its specification. However, some instances show long delays resulting in timeouts occasionally. Therefore **True** is the default. Setting this to **False** makes SCEPman return the issued certificate before Intune answers to the notification. This is against the letters of the specification, but increases performance and avoids timeouts in instances where this issue arises. ## AppConfig:IntuneValidation:ValidityPeriodDays *Linux: AppConfig\_\_IntuneValidation\_\_ValidityPeriodDays* **Value:** Positive *Integer* **Description:** This setting further reduces the global ValidityPeriodDays for the Intune endpoint. ## AppConfig:IntuneValidation:EnableCertificateStorage *Linux: AppConfig\_\_IntuneValidation\_\_EnableCertificateStorage* {% hint style="info" %} Applicable to version 2.7 and above SCEPman Enterprise Edition only {% endhint %} **Value:** *true* or *false* (default) **Description:** When requesting certificates via the Intune endpoint, SCEPman stores those requested certificates in the Storage Account in Azure if this is set to *true*. This will make the issued certificates appear in SCEPman Certificate Master, where you can view and revoke them manually. Additionally, certificates are revoked automatically when the associated Entra or Intune object goes into an invalid state as specified by the other settings (like being disabled or deleted). If set to *false*, SCEPman will not store issued certificates and the certificates are visible only in the logs or in the classic Intune view on Certificate Master or the Intune portal. If this is not set, the behavior depends on the global setting [AppConfig:EnableCertificateStorage](/scepman-configuration/application-settings/basics#appconfig-enablecertificatestorage). ## AppConfig:IntuneValidation:AllowRenewals **Value:** *true* or *false* (default) **Description:** This allows using the *RenewalReq* operation on this SCEP endpoint. It works only for certificate types added to *AppConfig:*IntuneValidation*:ReenrollmentAllowedCertificateTypes*. This operation can be used with the [SCEPmanClient ](https://github.com/scepman/scepmanclient)PowerShell module. {% hint style="warning" %} Please be aware that Intune will not make use of the *RenewalReq* operation and this setting is not required for usual operation. {% endhint %} ## AppConfig:IntuneValidation:AllowRequestedSidExtension {% hint style="info" %} Applicable to version 2.11.1460 and above. Previous versions behave differently than described if this setting is modified and we recommend to not configure this setting for these older versions. {% endhint %} **Value:** *true* or *false* (default) **Description:** If there is a SID extension (OID 1.3.6.1.4.1.311.25.2) in the certificate request, it will be copied to the issued certificate if this setting is true. If it is false, it will be filtered out. The SID is important for a strong mapping of certificates in on-premises AD authentication scenarios. However, Intune seemingly [does not check the authenticity of the requested SID](/other/troubleshooting/sid-spoofing-vulnerability) in the extension, so allowing requested SID extensions can pose a security vulnerability. SID extensions added via [AppConfig:AddSidExtension](/scepman-configuration/application-settings/certificates#appconfig-addsidextension) are not affected by this setting. Additionally, SIDs added as a SAN URI containing a SID are also unaffected if the SCEPman version is 2.11.1460 or newer — older versions of SCEPman copy the SAN URI SID only if this *true*, but they have *true* as default value. ## AppConfig:IntuneValidation:ReenrollmentAllowedCertificateTypes **Value:** Comma-separated list of certificate types from this list: * DomainController * Static * IntuneUser * IntuneDevice * JamfUser * JamfUserWithDevice * JamfUserWithComputer * JamfDevice * JamfComputer **Description:** You can use the SCEP endpoint for renewals of certificates of the types specified in this setting. If you do not specify any value, it defaults to no types. For example, if you wanted to renew certificates issued manually through Certificate Master, you would specify `Static`. If you also want to renew Domain Controller certificates, you would specify `DomainController,Static`. {% hint style="warning" %} Please be aware that Intune will not make use of the *RenewalReq* operation and this setting is not required for usual operation. {% endhint %} # Jamf Validation {% hint style="info" %} These settings should only be applied to the SCEPman App Service, not the Certificate Master. Please refer to [SCEPman Settings](/scepman-configuration/application-settings). {% endhint %} ## AppConfig:JamfValidation:Enabled *Linux: AppConfig\_\_JamfValidation\_\_Enabled* **Value:** *true* or *false* (default) **Description:** This setting helps you to request certificates via the [Jamf](https://github.com/scepman/scepman-docs/tree/6358a93fe3c35dd51ae9501a385049ad1c8feb0b/docs/certificate-deployment/jamf/general.md) MDM system. * **True**: SCEPman listens at the additional SCEP server endpoint with the path `/jamf`. Use in conjunction with [AppConfig:JamfValidation:RequestPassword](#appconfig-jamfvalidation-requestpassword). * **False** (default): SCEPman does not issue certificates for Jamf. ## AppConfig:JamfValidation:DefaultEkus *Linux: AppConfig\_\_JamfValidation\_\_DefaultEkus* {% hint style="info" %} Applicable to version 2.8 and above {% endhint %} **Value:** Oids of the extended key usages (EKUs) that are added to the certificate if the Jamf endpoint is used. The Oids are separated by a comma, semicolon, or space. The default is Client Authentication (1.3.6.1.5.5.7.3.2) **Description:** If a certificate request does not contain any EKUs, SCEPman adds the EKUs defined in this setting to the certificate. If [AppConfig:UseRequestedKeyUsages](/scepman-configuration/application-settings/certificates#appconfig-userequestedkeyusages) is set to *false*, the EKUs defined in this setting will be added to the certificate even if the certificate request contains EKUs. ## AppConfig:JamfValidation:DefaultKeyUsage *Linux: AppConfig\_\_JamfValidation\_\_DefaultKeyUsage* {% hint style="info" %} Applicable to version 2.8 and above {% endhint %} **Value:** EncipherOnly|CrlSign|KeyCertSign|KeyAgreement|DataEncipherment|*KeyEncipherment*|NonRepudiation|*DigitalSignature*|DecipherOnly (defaults are in *italic*) **Description:** If a certificate request does not contain a Key Usage, SCEPman adds the Key Usage defined in this setting to the certificate. If [AppConfig:UseRequestedKeyUsages](/scepman-configuration/application-settings/certificates#appconfig-userequestedkeyusages) is set to *false*, the Key Usage defined in this setting will be added to the certificate even if the certificate request contains a Key Usage. ## AppConfig:JamfValidation:RequestPassword *Linux: AppConfig\_\_JamfValidation\_\_RequestPassword* **Value:** *String* **Description:** A challenge password (max 32 characters) that Jamf must include in every SCEP request to acquire a certificate. Only used if [AppConfig:JamfValidation:Enabled](#appconfig-jamfvalidation-enabled) is set to *true*. We recommend defining this setting as Secret in Azure Key Vault. The Secret must have the name *AppConfig--JamfValidation--RequestPassword*. ## AppConfig:JamfValidation:ValidityPeriodDays *Linux: AppConfig\_\_JamfValidation\_\_ValidityPeriodDays* **Value:** Positive *Integer* **Description:** This setting further reduces the global [ValidityPeriodDays](/scepman-configuration/application-settings/certificates#appconfig-validityperioddays) for the Jamf endpoint. ## AppConfig:JamfValidation:URL *Linux: AppConfig\_\_JamfValidation\_\_URL* **Value:** *String* **Description:** The root URL of your Jamf instance. E.g. `https://your-instance.jamfcloud.com/`. Jamf instances with customer URLs and ports may be added e.g. `https://jamf.yourdomain.com:1234` ## AppConfig:JamfValidation:ClientID *Linux: AppConfig\_\_JamfValidation\_\_ClientID* {% hint style="info" %} Applicable to version 2.9 and above {% endhint %} **Value:** *String* **Description:** ClientID and ClientSecret are an alternative to APIUsername and APIPassword. Enter the Client ID of an API Client matching the Client Secret configured in the [AppConfig:JamfValidation:ClientSecret](#appconfig-jamfvalidation-clientsecret) setting. [Refer to the Jamf documentation](https://learn.jamf.com/en-US/bundle/jamf-pro-documentation-current/page/API_Roles_and_Clients.html) on how to create an API Role and API Client. The API Client must have a role with these permissions: * Read Mobile Devices * Read Computers * Read User ## AppConfig:JamfValidation:ClientSecret *Linux: AppConfig\_\_JamfValidation\_\_ClientSecret* {% hint style="info" %} Applicable to version 2.9 and above {% endhint %} **Value:** *String* **Description:** The Client Secret value for the API Client configuration in [AppConfig:JamfValidation:ClientID](#appconfig-jamfvalidation-clientid). We recommend to define this setting as Secret in Azure Key Vault. The Secret must have the name *AppConfig--JamfValidation--ClientSecret*. {% hint style="info" %} If you set this setting as a Secret in the Key Vault, you do not need to add the **AppConfig:JamfValidation:ClientSecret** to the SCEPman configuration anymore. {% endhint %} ## AppConfig:JamfValidation:APIUsername *Linux: AppConfig\_\_JamfValidation\_\_APIUsername* **Value:** *String* **Description:** Either use this and APIPassword or ClientID and ClientSecret.\ The name of a service account in Jamf that SCEPman uses to authenticate on your Jamf instance. SCEPman needs the following permissions to query for computers, devices, and users: * Computers -> Read * Mobile Devices -> Read * Users -> Read ## AppConfig:JamfValidation:APIPassword *Linux: AppConfig\_\_JamfValidation\_\_APIPassword* **Value:** *String* **Description:** The password of the service account configured in [AppConfig:JamfValidation:APIUsername](#appconfig-jamfvalidation-apiusername). We recommend defining this setting as Secret in Azure Key Vault. The Secret must have the name *AppConfig--JamfValidation--APIPassword*. {% hint style="info" %} If you set this setting as a Secret in the Key Vault, you do not need to add the **AppConfig:JamfValidation:APIPassword** to the SCEPman configuration anymore. {% endhint %} ## AppConfig:JamfValidation:EnableCertificateStorage *Linux: AppConfig\_\_JamfValidation\_\_EnableCertificateStorage* {% hint style="info" %} Applicable to version 2.3 and above SCEPman Enterprise Edition only {% endhint %} **Value:** *true* or *false* (default) **Description:** When requesting certificates via the Jamf endpoint, SCEPman stores those requested certificates in the Storage Account in Azure if this is set to *true*. This will make the issued certificates appear in SCEPman Certificate Master, where you can view and revoke them manually. Additionally, certificates are revoked automatically if the corresponding Jamf object is deleted. If set to *false*, SCEPman will not store issued certificates and the certificates are visible only in the logs or if the SCEP client stores them somewhere. If this is not set, the behavior depends on the global setting [AppConfig:EnableCertificateStorage](/scepman-configuration/application-settings/basics#appconfig-enablecertificatestorage). --- [Next Page](/llms-full.txt/1)