orchestrator
2021.10
false
- Getting Started
- Requirements
- Best Practices
- Installation
- Updating
- Identity Server
- Troubleshooting startup errors
Prerequisites for Installation
OUT OF SUPPORT
Orchestrator Installation Guide
Last updated Oct 31, 2024
Prerequisites for Installation
Apart from the prerequisites listed here for Orchestrator installation, Identity Server needs valid certificates.
Identity Server requires the following 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 fileappsettings.Production.json
, in the Signing Credential section.Note: 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.
You can employ 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:
- Specify the initial certificate's
Name
,Location
, andNameType
using theStoreLocation
parameter inappsettings.Production.json
’s SigningCredentialSettings section. Note that this is the default signing key. - Specify the second certificate's
Name
,Location
, andNameType
using theValidationKeys
parameter in the same section of theappsettings.Production.json
file. Make sure you complete this step before the rotation date. - 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. - 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.
- The previous certificate can be safely removed from the configuration after 48 hours.
In the following example,
SigningCredential
references the currently used certificate whereas ValidationKeys
references the newly published validation key.
"SigningCredentialSettings": {
"StoreLocation": {
"Name": "2816a67bc34496ca0acabbe04eb149b88ade0684",
"Location": "LocalMachine",
"NameType" : "Thumbprint",
"ValidationKeys": [
{
"Name": "2cde6c443f0147c6258a6fe2203e71a997bfcd44",
"Location": "LocalMachine",
"NameType" : "Thumbprint"
}
]
}
}
"SigningCredentialSettings": {
"StoreLocation": {
"Name": "2816a67bc34496ca0acabbe04eb149b88ade0684",
"Location": "LocalMachine",
"NameType" : "Thumbprint",
"ValidationKeys": [
{
"Name": "2cde6c443f0147c6258a6fe2203e71a997bfcd44",
"Location": "LocalMachine",
"NameType" : "Thumbprint"
}
]
}
}
Important: If you are using AI Center, make sure to redeploy it whenever updating the Identity Server certificate.