PKI Certificate Requirements
For multi-node integrated Azure Stack Hub systems, the Cloud Assert Resource Providers (RP) need their own PKI certificate during deployment with the appropriate DNS name
Certificate Requirements
The following list describes the certificate requirements that are needed to deploy Cloud Assert Resource Providers for Azure Stack Hub:
Certificates must be issued from either an internal certificate authority or a public certificate authority. If a public certificate authority is used, it must be included in the base operating system image as part of the Microsoft Trusted Root Authority Program. For the full list, see Microsoft Trusted Root Certificate Program: Participants.
Your Azure Stack Hub infrastructure must have network access to the certificate authority's Certificate Revocation List (CRL) location published in the certificate. This CRL must be an http endpoint.
The use of self-signed certificates aren't supported.
For deployment and rotation, you can either use a Wildcard SSL certificate or a SAN certificate.
The certificate's PFX Encryption should be 3DES.
The certificate signature algorithm shouldn't be SHA1.
The certificate format must be PFX, as both the public and private keys are required for Cloud Assert RP installation. The private key must have the local machine key attribute set.
The PFX encryption must be 3DES (this encryption is default when exporting from a Windows 10 client or Windows Server 2016 certificate store).
The certificate pfx files must have a value "Digital Signature" and "KeyEncipherment" in its "Key Usage" field.
The certificate pfx files must have the values "Server Authentication (1.3.6.1.5.5.7.3.1)" and "Client Authentication (1.3.6.1.5.5.7.3.2)" in the "Enhanced Key Usage" field.
The certificate's "Issued to:" field must not be the same as its "Issued by:" field.
Password to the certificate pfx has to be a complex password. Make note of this password because you'll use it as a deployment parameter. The password must meet the following password complexity requirements:
A minimum length of eight characters.
At least three of the following characters: uppercase letter, lowercase letter, numbers from 0-9, alphabetical character that's not uppercase or lowercase, special characters except:
^ ` ~ & % *
Ensure that the subject names and subject alternative names in the subject alternative name extension (x509v3_config) match. The subject alternative name field lets you specify additional host names (websites, IP addresses, common names) to be protected by a single SSL certificate.
Certificate with the appropriate DNS name is required. Each Cloud Assert RP endpoint's DNS name is expressed in the format: <prefix>.<region>.<fqdn>
For your deployment, the [region] and [externalfqdn] values must match the region and external domain names that you chose for your Azure Stack Hub system. As an example, if the region name was Redmond and the external domain name was contoso.com, the DNS names would have the format <prefix>.redmond.contoso.com.
The required certificate subject and subject alternative names (SAN) for the Cloud Assert RPs is: *.cloudassert.<region>.<fqdn>
Self-signed certificates aren't supported.
When deploying the Cloud Assert RP in an Azure Stack Hub stamp setup in disconnected mode it is recommended to use certificates issued by an enterprise certificate authority. This is important because clients accessing Cloud Assert RP endpoints must be able to contact the certificate revocation list (CRL).
The presence of Intermediary Certificate Authorities in a certificate's chain-of-trusts is supported.
Generate Certificate Signing Request (CSR)
Prerequisite Certificate Attributes
Region name
External fully qualified domain name (FQDN)
Subject (in the format below)
"E=<email address>, C=<two-letter ISO country code>, O=<Organization Name>, L=<Location>, S=<State>, OU=<Organization Unit>, CN=*.cloudassert.<Azure Stack Hub External FQDN>"Generate the CSR in a machine with Windows 10 or Windows Server 2016 or later
Create a request .INF file with the requisite certificate signing request information.
Sample INF files are available here. For a Wildcard SSL certificate, refer to “CSR Template - Wildcard.inf”. For a SAN certificate, refer to “CSR Template - SAN.inf”.
If you are generating a Wildcard SSL certificate, update the Subject attribute in the sample INF file by replacing the placeholder text.
If you are generating a SAN certificate, update the Subject and szOID_SUBJECT_ALT_NAME2 attributes in the sample INF file by replacing the placeholder text.
Use the certreq utility to generate the CSR by following the command below. Ensure that you specify the output CSR request file (.REQ)
certreq -New "<Path to input CSR INF file>" "<Path to output CSR REQ file>"Review the output CSR Request file by using an online CSR decoding utility (e.g., https://www.sslshopper.com/csr-decoder.html)
Submit the .REQ file generated to your CA (either internal or public). Be sure that your CA generates certificates using your generated request that meet the Certificate Requirements described section above.
More Information
Last updated