Disclaimer: I do not accept responsibility for any issues arising from scripts being run without adequate understanding. It is the user's responsibility to review and assess any code before execution. More information

Microsoft Entra ID Certificate-Based Authentication Setup

byartic6 -
0


If your organization has its own internal certificate authorities, you'll need to configure PKI in Entra ID so your tenant trusts certificates issued by those internal CAs. Without this setup, Entra ID will reject your internal certificates as untrusted, which means certificate-based authentication won't work for your users. 

Note: Adding these certificate authorities only establishes trust - it doesn't automatically enable certificate-based authentication, which is a separate feature that needs to be configured in Part 2.

Part 1: Configuring Public Key Infrastructure (PKI)

Prerequisites

  • Global Administrator or Authentication Policy Administrator role
  • Valid X.509 certificates from your Certificate Authority
  • CRL distribution points properly configured (if using CRL validation)
Provide the “full” chain

When you have a certificate hierarchy (root CA with intermediate/issuing CAs), you need to provide Entra ID with the complete certificate chain in a single file.

If you simply provide the “root” certificate then the chain will be incomplete and verification will not work because it will not trust the intermediary authority certificate servers - we therefore need to create this correct certificate chain in a single file.

The format should be:

  • Base64 encoded
  • Root certificate at the top
  • Followed by intermediate certificates in order (closest to root first)

So your certificate stack would look like:

-----BEGIN CERTIFICATE-----
[Root CA certificate in base64]
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
[Intermediate CA 1 certificate in base64]
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
[Intermediate CA 2 certificate in base64]
-----END CERTIFICATE-----

This gives Entra ID the full chain of trust from your root down to the issuing certificate authorities, allowing it to properly validate certificates issued by any CA in your hierarchy.

Step 1: Access the PKI Section

  1. Sign in to the Microsoft Entra admin center (https://entra.microsoft.com)
  2. Navigate to Protection > Authentication methods
  3. Select Certificate-based authentication
  4. Click on the Public key infrastructure tab

Step 2: Create a New PKI Configuration

  1. Click + New PKI
  2. Provide a descriptive name for your PKI configuration
  3. Click Create

Step 3: Upload Certificate Authorities

For each Certificate Authority in your chain (Root CA and any Intermediate CAs):

  1. Prepare the certificate in Base64 format:

    • Export your CA certificate as Base64 encoded X.509 (.CER)
    • Open the certificate file in a text editor
    • Copy the entire content including the BEGIN/END CERTIFICATE lines

  2. Upload the certificate:

    • Click + Add certificate authority
    • Certificate Authority Name: Enter a descriptive name
    • Certificate: Paste the Base64 encoded certificate content
    • Issuer: This will auto-populate from the certificate
    • Subject: This will auto-populate from the certificate

  3. Configure CRL Distribution Point (if applicable):

    • CRL Distribution Point URL: Enter the HTTP URL where the CRL is published
    • Example: http://crl.pokebearswithsticks.com/contoso-ca.crl
    • Ensure the CRL is accessible via HTTP (not HTTPS for compatibility)

  4. Validation Settings:

    • Delta CRL supported: Enable if your CA supports delta CRLs
    • CRL offline tolerance: Set the acceptable time window for CRL staleness

  5. Click Add to save the certificate authority

Step 4: Verify PKI Configuration

  • Review all uploaded certificate authorities
  • Ensure the certificate chain is complete (Root → Intermediate → End-entity)
  • Verify CRL distribution points are accessible and functional

Part 2: Enabling Certificate-Based Authentication

Step 1: Enable the Authentication Method

  1. In the Certificate-based authentication settings
  2. Set Enable to Yes
  3. Configure the target users/groups who can use this method

Step 2: Configure Certificate Revocation List (CRL) Validation

Require CRL validation (recommended):

  • Enable: Turn this ON for enhanced security
  • Impact: Every certificate will be checked against the CRL
  • Failure condition: Authentication fails if CRL is unreachable or certificate is revoked

CRL Validation Exemptions:

  • Use sparingly and only for trusted internal CAs
  • Click Add exemption to exclude specific certificate authorities
  • Select the CA from your configured PKI list

Step 3: Configure Issuer Hints

Enable issuer hints:

  • Purpose: Shows only valid certificates in the certificate picker
  • User Experience: Reduces confusion during authentication
  • Recommendation: Enable for better user experience

Setting: Enable issuer hints = Yes

Step 4: Configure Authentication Binding

Default Authentication Strength:

  • Single-factor: Certificate alone counts as one factor
  • Multi-factor: Certificate alone counts as two factors

Required Affinity Binding:

  • Low: Less restrictive certificate-to-user binding
  • High: Stricter certificate-to-user binding requirements

Custom Authentication Binding Rules: Create specific rules for different certificate issuers:

  1. Click + Add rule
  2. Certificate issuer: Select from your configured PKI
  3. Policy OID: Enter specific OID if required (optional)
  4. Authentication strength: Override default setting
  5. Affinity binding: Override default affinity level

Step 5: Configure Username Binding

This determines how certificate fields map to user attributes:

Default Bindings:

  1. PrincipalName → userPrincipalName (Low affinity)

    • Maps certificate principal name to UPN
    • Most common binding method

  2. RFC822Name → userPrincipalName (Low affinity)

    • Maps certificate email field to UPN
    • Useful for email-based certificates

  3. SKI → CertificateUserIDs (High affinity)

    • Maps Subject Key Identifier to certificate user IDs
    • Highest security binding

Custom Username Binding:

  1. Click + Add binding
  2. Certificate field: Choose from available X.509 fields
  3. User attribute: Select corresponding Entra ID attribute
  4. Affinity binding: Set Low or High based on trust level

Step 6: Configure Certificate Issuer Scoping Policy 

Restrict specific certificate issuers to designated user groups:
  1. Click + Add scoping rule
  2. PKI: Select your configured PKI
  3. Certificate issuer: Choose specific CA
  4. SKI: Subject Key Identifier of the issuer
  5. Target group: Select Entra ID group for authorization
  6. Validity Status: Enable/Disable the rule

Part 3: Troubleshooting Common Issues

Certificate Not Appearing in Picker

  • Verify certificate chain is complete in PKI configuration
  • Check issuer hints configuration
  • Ensure certificate is not expired or revoked

CRL Validation Failures

  • Verify CRL distribution point URL is accessible
  • Check CRL is current and not expired
  • Consider CRL exemptions for internal CAs (carefully)

Username Binding Issues

  • Verify certificate fields contain expected values
  • Check user attribute mappings in Entra ID
  • Review affinity binding settings

Authentication Strength Not Applied

  • Check authentication binding rules
  • Verify policy OID matches (if specified)
  • Review conditional access policies

This should then give you an trusted public key infrastructure (PKI) which when complete can be trusted by Entra and not marked as "untrusted"

Tags
Previous Post Next Post

نموذج الاتصال