Introducing Trusted Certificate Authorities (public preview) in App management policy

Saurabh Madan

In March 2023, we launched ‘App management policy’, a general-purpose framework that enables admins to implement security best practices for applications in their tenant. Currently, the framework has a variety of controls to restrict authentication methods that can be used in applications. These controls help improve the credential hygiene of applications and service principals. For example, an IT admin can restrict the use of password secrets on all applications created after a certain date (e.g., 01/01/2020) by creating a policy that restricts developers from adding secrets. More information on the App management policy API is available here.

The following screenshot shows what a sample policy with restrictions on the application password (client secrets) and key credentials (certificate) lifetime would like:

We have recently added a new capability (public preview) that enables admins to define trusted certificate issuers for their tenant. When this policy is deployed, attempts to add a certificate that does not meet the criteria defined in policy will be rejected.

What is a chain of trust?

Before we go any further, let us look at how a chain of trust is established. In a certificate chain of trust, each certificate is signed by its parent’s private keys. In the example below, the chain builds upwards where the leaf certificate (top left) is signed by an intermediate certificate, and the intermediate certificate is signed by the root certificate. This chaining allows for the validation and trustworthiness verification of a certificate.

Trust chain example

Why restrict the chain of trust?

As an admin, you can now enforce security best practices such as not allowing self-signed certificates in your applications. Self-signed certs have many issues, one of them being the lack of an authoritative issuer which makes it hard to trace the origins and validity of a self-signed cert. This can lead to multiple problems such as the lack of an audit trail or the use of weak encryption in certs, which can lead to an app being compromised. Establishing a trust certificate authorities store will help you raise the security bar for your applications and will provide an additional layer of defense to prevent apps from being compromised.

How to enable the policy in your tenant?

Creating and enforcing a trusted authority is a simple two-step process.

1. Create a certificate chain of trust.
2. Add trusted certificate authority collection to App management policy.

Step 1 – Create a certificate chain of trust

The following sample creates a certificateBasedApplicationConfiguration object that represents a part of a certificate chain of trust. This object includes two certificate issuers: one is the main authority (root), and the other is an intermediate certificate signed by the main authority. Note, the isRootAuthority property is set to true for the first object in the payload. The response has the id of this trust chain. We will use this id eec5ba11… in our next step to join this trust chain with the application management policy. You can find the API documentation in the Microsoft Graph API docs.

Request

POST https://graph.microsoft.com/beta/certificateAuthorities/certificateBasedApplicationConfigurations

{
  "displayName": "Trusted Certificate Chain of Trust for Contoso",
  "description": "The Trusted Certificate Chain of Trust containing a certificate chain used by app policy, to only allow application certificates from selected issuer.",
  "trustedCertificateAuthorities": [{
    "isRootAuthority": true,
    "certificate": "MIIFVjCCAz6gAwIBAgIQJdrLVcnGd4FAnlaUgt5N/jANBgkqhkiG9w0BAQsFADA8MRMwEQYKCZImiZPyLGQBGRYDR0JMMRMwEQYKCZImiZPyLGQBGRYDQU1FMRAwDgYDVQQDEwdhbWVyb290MB4XDTE2MDUyNDIyNTI1NFoXDTI2MDUyNDIyNTcwM1owPDE …="
  },
  {
    "isRootAuthority": false,
    "certificate": "MIIIcTCCBlmgAwIBAgITHwAAAFr7ZWQR1r6OSQAAAAAAWjANBgkqhkiG9w0BAQsFADA8MRMwEQYKCZImiZPyLGQBGRYDR0JMMRMwEQYKCZImiZPyLGQBGRYDQU1FMRAwDgYDVQQDEwdhbWVyb290MB4XDTIxMDkwMTIxNDMzN1oXDTI2MDUyNDIyNTcwM1o …="
  }]
}

Response

{
    "@odata.context": "https://graph.microsoft.com/beta/$metadata#certificateAuthorities/certificateBasedApplicationConfigurations/$entity",
    "id": "eec5ba11-2fc0-4113-83a2-ed986ed13743",
    "deletedDateTime": null,
    "displayName": "Trusted Certificate Chain of Trust for Contoso",
    "description": "The Trusted Certificate Chain of Trust containing a certificate chain used by app policy, to only allow application certificates from selected issuer."
}

Step 2 – Add trusted certificate authority collection id to default application management policy

The following sample sets up a policy to ensure that application certificates are only issued by the intermediate certificate authority defined in step #1. This policy would reject any attempts to add a certificate that doesn’t meet the criteria specified in the policy. With the certificate chain of trust created in the previous step, we will take the chain id and add it to the default App management policy. Doing so in the tenant default policy will enforce compliance on all applications in a tenant.

You can find the App management policy configuration docs here.

Note: the enforcement of the policy happens during app management operations. So, even if the policy applies some restrictions, it wouldn’t just break all apps. Unless an app tries to rotate its credentials (in this case, certificates) they will continue to work and get tokens. When the app does try to rotate its credentials, it will then go through the policy evaluation to ensure the credentials being added comply with the trusted certificate authority restriction.

PATCH https://graph.microsoft.com/beta/policies/defaultAppManagementPolicy

{
  "id": "d015220e-9789-4e8e-bbcc-270fe419229d",
  "description": "Lorem ipsum",
  "displayName": "Credential management policy",
  "isEnabled": true,
  "applicationRestrictions": {
    "passwordCredentials": [
      {
        "restrictionType": "passwordLifetime",
        "maxLifetime": "P14D",
        "restrictForAppsCreatedAfterDateTime": "2020-01-01T07:00:00Z"
      }
    ],
    "keyCredentials": [
      {
        "restrictionType": "certificateLifetime",
        "restrictForAppsCreatedAfterDateTime": "2020-01-01T10:37:00Z",
        "maxLifetime": "P90D"
      },
      {
        "restrictionType": "trustedCertificateAuthority",
        "certificateBasedApplicationConfigurationIds": [
          "eec5ba11-2fc0-4113-83a2-ed986ed13743"
        ],
        "restrictForAppsCreatedAfterDateTime": "2019-10-19T10:37:00Z"
      }
    ]
  }
}

Based on the sample configuration above, an attempt to add a self-signed cert will result in an error.

Roles and permissions

Configuring and managing the app certificate trust store and the app policy requires specific roles and permissions. Both configurations require an administrative role and permissions associated with each API.

Managing the app certificate trust store

• Roles: Application administrator, Cloud application administrator, and Global administrator.
• Permissions: AppCertTrustConfiguration.ReadWrite.All, AppCertTrustConfiguration.Read.All

Managing the App management policy

• Roles: Application administrator, Security administrator, and Global administrator.
• Permissions: Policy.Read.All, Policy.ReadWrite.ApplicationConfiguration

Tips

Here are a few noteworthy things you should remember.

• trustedCertificateAuthorities requires that at least one entity be declared as a root in the collection.
• trustedCertificateAuthorities can store a max of 10 objects per collection, which means that you can add a cert chain with up to a max of 10 objects in a single chain.
• certificateBasedApplicationConfiguration can store a max of 10 objects per collection. This includes soft-deleted and active objects. The trusted chain configuration requires the full chain to be added. For example, if you have an intermediate certificate issuing authority that chains up to a root which is common amongst all intermediates, each chain must be defined separately.
• An App management policy which enforces the trusted certificate authority supports a max of 5 trusted cert authorities.

More details and Microsoft Graph API documentation is available here.

Licensing

App management policy is part of the Microsoft Entra Workload ID premium offering, and this feature requires you to have a premium license. Your license can be viewed or acquired via the Workload Identities blade in the Entra admin portal.

We want your feedback

We’d love to hear your thoughts and feedback on this feature. Let us know by clicking on the Got feedback? button in the Azure Portal.

Saurabh Madan Product Manager

Follow