SSL/TLS certificate requirements for on-premises resources
This article is one in a series of articles describing the deployment path for OT monitoring with Microsoft Defender for IoT.
Use the content below to learn about the requirements for creating SSL/TLS certificates for use with Microsoft Defender for IoT appliances.
Defender for IoT uses SSL/TLS certificates to secure communication between the following system components:
- Between users and the OT sensor or on-premises management console UI access
- Between OT sensors and an on-premises management console, including API communication
- Between an on-premises management console and a high availability (HA) server, if configured
- Between OT sensors or on-premises management consoles and partners servers defined in alert forwarding rules
Some organizations also validate their certificates against a Certificate Revocation List (CRL) and the certificate expiration date, and the certificate trust chain. Invalid certificates can't be uploaded to OT sensors or on-premises management consoles, and will block encrypted communication between Defender for IoT components.
Important
You must create a unique certificate for each OT sensor, on-premises management console, and high availability server, where each certificate meets required criteria.
Supported file types
When preparing SSL/TLS certificates for use with Microsoft Defender for IoT, make sure to create the following file types:
| File type | Description |
|---|---|
| .crt – certificate container file | A .pem, or .der file, with a different extension for support in Windows Explorer. |
| .key – Private key file | A key file is in the same format as a .pem file, with a different extension for support in Windows Explorer. |
| .pem – certificate container file (optional) | Optional. A text file with a Base64-encoding of the certificate text, and a plain-text header and footer to mark the beginning and end of the certificate. |
CRT file requirements
Make sure that your certificates include the following CRT parameter details:
| Field | Requirement |
|---|---|
| Signature Algorithm | SHA256RSA |
| Signature Hash Algorithm | SHA256 |
| Valid from | A valid past date |
| Valid To | A valid future date |
| Public Key | RSA 2048 bits (Minimum) or 4096 bits |
| CRL Distribution Point | URL to a CRL server. If your organization doesn't validate certificates against a CRL server, remove this line from the certificate. |
| Subject CN (Common Name) | domain name of the appliance, such as sensor.contoso.com, or .contosocom |
| Subject (C)ountry | Certificate country code, such as US |
| Subject (OU) Org Unit | The organization's unit name, such as Contoso Labs |
| Subject (O)rganization | The organization's name, such as Contoso Inc. |
Important
While certificates with other parameters might work, they aren't supported by Defender for IoT. Additionally, wildcard SSL certificates, which are public key certificates that can beused on multiple subdomains such as .contoso.com, are insecure and aren't supported. Each appliance must use a unique CN.
Key file requirements
Make sure that your certificate key files use either RSA 2048 bits or 4096 bits. Using a key length of 4096 bits slows down the SSL handshake at the start of each connection, and increases the CPU usage during handshakes.
Supported characters for keys and passphrases
The following characters are supported for creating a key or certificate with a passphrase:
- ASCII characters, including a-z, A-Z, 0-9
- The following special characters: ! # % ( ) + , - . / : = ? @ [ \ ] ^ _ { } ~