Meine Organisation verfügt über eine eigene Zertifizierungsstelle (CA) auf einem unserer Windows Server 2008 R2-Rechner und eine lokale Intranet-Website, die SSL verwendet. Mein Vorgänger hat 2016 ein Zertifikat erstellt, das die Anforderungen von Chrome und FireFox nicht mehr erfüllt. Seitdem ist dieses Zertifikat abgelaufen und wurde nicht erneuert. Ich habe das Zertifikat erneuert und es in den vertrauenswürdigen Stammzertifizierungsstellen auf dem Remotecomputer installiert. FireFox und Chrome behaupten nun, dass das Zertifikat ungültig sei. FireFox sagt, dass es eine schwache Verschlüsselung verwendet, und Chrome sagt einfach, dass es ohne Grund ungültig ist ... aber auf dem Bildschirm „Zertifikatdetails“ wird gesagt, dass das Zertifikat in Ordnung ist (?).
Die Zertifizierungsstelle wird derzeit von Windows Server 2008 R2 bis IIS 6 verwaltet.
Meine Frage ist, wie ich IIS und das Zertifikat konfigurieren kann, um diese Anforderungen zu erfüllen?
Zertifikat befindet sich unter C:/Windows/System32/certsrv/CertEnroll
X509 Certificate:
Version: 3
Serial Number: 6464d31bb0aeefa44bea96fe13c****
Signature Algorithm:
Algorithm ObjectId: 1.2.840.113549.1.1.11 sha256RSA
Algorithm Parameters:
05 00
Issuer:
CN=*******
NotBefore: 11/11/2016 9:30 AM
NotAfter: 11/11/2021 9:40 AM
Subject:
CN=******
Public Key Algorithm:
Algorithm ObjectId: 1.2.840.113549.1.1.1 RSA
Algorithm Parameters:
05 00
Public Key Length: 2048 bits
Public Key: UnusedBits = 0
0000 30 82 01 0a 02 82 01 01 00 bb 58 5d e8 11 4f 57
0010 aa 37 3a 21 af 8e ab 20 24 36 6f f6 6e c9 6b d9
0020 d7 10 7f e4 e6 26 0c ee e0 67 41 bd 0d 4d 2c 1c
0030 56 ec 20 7a 80 5d bc f9 ed 8d a9 4d d9 ac b6 f7
0040 24 18 2f 19 ae 35 d9 f3 a6 0a 1a 76 c3 07 c2 bb
******************
Certificate Extensions: 4
2.5.29.15: Flags = 0, Length = 4
Key Usage
Digital Signature, Certificate Signing, Off-line CRL Signing, CRL Signin
g (86)
2.5.29.19: Flags = 1(Critical), Length = 5
Basic Constraints
Subject Type=CA
Path Length Constraint=None
2.5.29.14: Flags = 0, Length = 16
Subject Key Identifier
a9 ab c3 52 50 8d 20 07 17 2d a0 7f 9d a9 ******
1.3.6.1.4.1.311.21.1: Flags = 0, Length = 3
CA Version
V0.0
Signature Algorithm:
Algorithm ObjectId: 1.2.840.113549.1.1.11 sha256RSA
Algorithm Parameters:
05 00
Signature: UnusedBits=0
0000 1e b8 e5 7e 93 d4 e4 1c 5b 23 12 14 b3 44 14 cb
0010 1a 22 a1 ab 7d 2e 72 2c af 20 76 0b d5 93 02 58
0020 d7 44 85 76 5d 97 c5 58 ba 48 53 e7 ab e8 f6 e2
0030 15 a8 90 6b 53 bd 9f 04 54 b0 a0 07 94 89 f5 01
0040 74 bc e9 0c 03 98 52 89 f6 5d 53 7a 42 ae 70 43
***************
Signature matches Public Key
Root Certificate: Subject matches Issuer
Key Id Hash(rfc-sha1): a9 ab c3 52 50 8d 20 07 17 ********
Key Id Hash(sha1): 17 52 93 4f ea 7d 37 58 df 80 e3 a8 ********
Cert Hash(md5): 88 8f 26 47 51 73 25 8a 3d d8 56 ********
Cert Hash(sha1): e2 fb 4e 43 b7 2e 35 00 fa 7b a8 8c ******
CertUtil: -dump command completed successfully.
Antwort1
Ihr Zertifikat hat fast keinen Einfluss auf die verwendete Verschlüsselung. Dafür sind die in Ihrem (unbekannten) Webserver konfigurierten Cipher Suites verantwortlich und das Zertifikat hat nur einen geringen Einfluss darauf, welche Cipher Suites verfügbar sind (RSA-Zertifikate benötigen z. B. Ciphers mit RSA-Authentifizierung).
Aus diesem Grund macht es keinen Sinn, ein „stärkeres“ Zertifikat zu erwerben. Stattdessen sollten Sie Ihren Webserver so konfigurieren, dass er die stärkeren Verschlüsselungssammlungen unterstützt, insbesondere alle Verschlüsselungen mit RSA-Schlüsselaustausch verbieten oder zumindest deren Priorität verringern.
Was die Stärke des Zertifikats selbst betrifft, die für die Authentifizierung relevant ist: Sie müssen einen starken öffentlichen Schlüssel (mindestens 2048 Bit, wenn Sie bei RSA bleiben) und mindestens SHA-256 als Signaturalgorithmus verwenden.