Apart from the prerequisites listed here for Orchestrator installation, Identity Server needs the following:

Certificates

Identity Server requires 2 valid certificates:

• A certificate for the HTTPS protocol.
• A certificate used to sign the tokens generated by the Identity Server.

🚧

Important!

For security reasons, the certificate used by the Identity Server needs to:
have a public key on 2048 bits
have a private key accessible by the AppPool user,
be in its validity period (not expired).

The certificate's location is set in Identity Server's configuration file appsettings.Production.json, in the Signing Credential section.

If a self-signed certificate is used, this must also be placed in the Trusted Root Certification Authority certificate store (besides the usual Personal location).

The certificate is used for signing OpenID access tokens that are used for user identification via browser and for service-to-service communication between Orchestrator and Identity Server. Click here for more details about OpenID Connect.

Certificate Rotation

You can resort to certificate rotation to avoid the risk of certificate expiration and, implicitly, an Identity Server outage. This method entails maintaining two certificates and rotating them periodically. Note, however, that you can only use one signing key at a time.

To initiate the certificate rotation process, take the following steps:

1. Specify the initial certificate's Name, Location, and NameType using the SigningCredential parameter in appsetting.Production.json’s SigningCredential section. Note that the first signing key you register is the default.
2. Specify the second certificate's Name, Location, and NameType using the ValidationKeys parameter in the same section of the appsetting.Production.json file. Make sure you complete this step before the rotation date.
3. At this stage, the second certificate is published using the identity/.well-known/openid-configuration/jwks endpoint. This ensures everyone has enough time to update their cached discovery document.
4. At rotation time, switch the certificates and restart Identity Server. The new certificate can now be used for signing whereas the previous one continues to be available for validation purposes for as long as you need.

In the following example, SigningCredential references the currently used certificate whereas ValidationKeys references the newly published validation key.

"SigningCredentialSettings": {
      "StoreLocation": {
        "SigningCredential": {
            "Name": "2816a67bc34496ca0acabbe04eb149b88ade0684",
            "Location": "LocalMachine",
            "NameType" : "Thumbprint"
        },
        "ValidationKeys": [
            {
            "Name": "2cde6c443f0147c6258a6fe2203e71a997bfcd44",
            "Location": "LocalMachine",
            "NameType" : "Thumbprint"
            }
        ]
      }
    }