Nous recevons souvent des questions sur la manière d'appliquer des politiques qui permettent aux autorités de certification de ne délivrer que des types spécifiques de certificats ou des certificats qui ne peuvent être utilisés que dans des cas d'utilisation très spécifiques. Une question de plus en plus fréquente porte sur la manière de restreindre, ou de "verrouiller", les applications tierces de proxy/interceptionSSL telles que Zscaler, F5 ou Palo Alto.
Pourquoi restreindre le certificat ?
Une application SSL Intercept agit comme une application man-in-the-middle qui veut émettre des certificats en temps réel en se faisant passer pour les serveurs web de destination. Ces certificats permettent une surveillance autorisée des connexions SSL . Ces applications créent leurs propres CSR nécessitant un certificat de sous-autorité de certification afin de pouvoir émettre leurs propres certificats en tant qu'autorité de certification. Cela pose immédiatement des problèmes de sécurité, car l'émission d'un certificat de sous-autorité de certification pour une application intermédiaire fait de cette application une autorité de certification émettrice. Si cette application était compromise, le certificat de l'autorité de certification secondaire pourrait être utilisé pour émettre des certificats de confiance, des LCR signées ou d'autres certificats de l'autorité de certification secondaire.
Généralement, les RSC sont publiés avec deux questions principales :
- Non Contrainte de longueur de chemin
- Pas de politique affirmée
Toutefois, ces applications peuvent demander des fonctionnalités supplémentaires qu'il ne devrait pas avoir, telles que la signature de code ou la signature OCSP.
Lorsqu'un certificat d'autorité de certification secondaire est nécessaire pour ces applications, il doit avoir un minimum de fonctionnalités.
Quelle est l'alternative ?
Normalement, nous signerions à nouveau la CSR avec un nouveau fichier policy.inf qui utilise les contraintes de la stratégie d'application de Microsoft pour restreindre l'utilisation du certificat. Cette méthode fonctionne avec les autorités de certification Microsoft, car les contraintes de politique d'application sont une norme Microsoft, mais elle ne s'applique pas aux appliances d'autorité de certification dont les demandes ne portent pas sur des modèles de certificats Microsoft v2. Les contraintes de la politique d'application sont effectivement ignorées par le proxy ou l'application d'interception SSL .
Restriction de l'utilisation du certificat
Afin d'empêcher l'application d'interception ou de proxy SSL de délivrer des certificats dont les fonctionnalités vont au-delà de ce qu'elle devrait faire, nous ajouterons une extension "Enhanced Key Usage" à la demande. Normalement, les autorités de certification secondaires ne spécifient pas d'EKU et l'ajout d'une nouvelle section EKU au fichier policy.inf aura deux effets :
- N'incluez que ces EKU spécifiques dans le certificat de l'autorité de certification secondaire.
- Remplacer les EKU demandées dans la CSR.
La CSR devra être signée par l'autorité de certification racine ou par une autorité de certification de politique avec l'adresse command:
- Certreq - politique "original_CSR.req" "Policy_file.inf" "new_request.req"
Par exemple, le fichier Policy_file.inf pourrait ressembler à ceci :
[Version]
Signature="$Windows NT$"
[Chaînes]
DefaultPolicyOID = "1.2.3.4.1455.67.89.5"
PolicyNotice = "Cette autorité de certification est une AC de proxy web privée. Les certificats délivrés par cette autorité de certification ne sont pas gérés et peuvent ne pas être conformes à une quelconque politique. Pour plus d'informations, veuillez consulter : https://CDP.contoso.com/PKI/cps.txt"
PolicyURL = "https://CDP.contoso.com/PKI/cps.txt"
[PolicyStatementExtension]
Politiques = Politique par défaut
[Politique par défaut]
OID = %DefaultPolicyOID% (identifiant de la politique par défaut)
NOTICE="%PolicyNotice%"
URL="%PolicyURL%"
[EnhancedKeyUsageExtension]
OID = 1.3.6.1.5.5.7.3.1 ; Authentification du serveur
[Extensions]
2.5.29.19 = "{text}ca=1&pathlength=0"
2.5.29.15 = AwIBBg==
Critique = 2.5.29.19,2.5.29.15
Cela produira une CSR qui, une fois signée, générera un certificat avec les EKU spécifiés. Une fois le certificat installé sur l'application SSL Intercept ou Proxy, l'application ne pourra émettre des certificats qu'avec les politiques définies dans l'EKU du certificat de l'autorité de certification secondaire.
Résumé
Si vous avez besoin d'un certificat d'autorité de certification secondaire pour une application d'interception ou de proxy SSL , envisagez de résigner le CSR pour appliquer une politique, une restriction de longueur de chemin et une restriction EKU afin d'empêcher l'application de générer des certificats avec des utilisations au-delà de ce qui est nécessaire.
