So richten Sie die openssl-Zertifizierungsstelle ordnungsgemäß ein, um SSL-Clientzertifikate zu generieren

Ich konfiguriere meine erste Zertifizierungsstelle. Ziel ist es, Zertifikate für unsere Kunden auszustellen, die sie verwenden, um über https auf unseren EDI-Service zuzugreifen. Ich muss also SSL-Client-Zertifikate generieren. Der gesamte Prozess des Signierens von Zertifikaten funktioniert inzwischen, und die Zertifikate können erfolgreich für den Zugriff auf unseren Service verwendet werden. Ich mache mir jedoch Sorgen um eines:

Die generierten Zertifikatzwecke sind viel zu allgemein:

$ openssl x509 -purpose  -noout -in client.crt.pem
Certificate purposes:
SSL client : Yes
SSL client CA : No
SSL server : Yes
SSL server CA : No
Netscape SSL server : Yes
Netscape SSL server CA : No
S/MIME signing : Yes
S/MIME signing CA : No
S/MIME encryption : Yes
S/MIME encryption CA : No
CRL signing : Yes
CRL signing CA : No
Any Purpose : Yes
Any Purpose CA : Yes
OCSP helper : Yes
OCSP helper CA : No

Ich bin der Meinung, dass es in meinem Fall keine anderen Zwecke als SSL-Client und S / MIME-Signierung geben sollte. Bin ich falsch und das sollte so bleiben wie es ist?

Was soll ich in meine openssl.cnf-Konfiguration einfügen, wenn ich korrekt bin und andere Zwecke deaktivieren sollte?

Hier ist meine aktuelle Konfiguration (etwas entfernt):

[ CA_edi ]
# here was directory setup and some other stuff, cut it for clarity
x509_extensions = usr_cert      # The extentions to add to the cert

name_opt    = ca_default        # Subject Name options
cert_opt    = ca_default        # Certificate field options
# Extension copying option: use with caution.
# copy_extensions = copy
# stripped rest of config about validity days and such

[ usr_cert ]

basicConstraints=CA:FALSE
nsCertType = client, email
keyUsage = nonRepudiation, digitalSignature, keyEncipherment, keyAgreement

Was mache ich falsch, dass die generierten Zertifikate die Servernutzung ermöglichen?

Sie sind zu Recht besorgt über "CRL-Signierung", "Any Purpose CA" und "OCSP Helper". Diese sind normalerweise CA-Zertifikaten oder Zertifikaten vorbehalten, die speziell für das Signieren von Zertifikatsperrlisten (CRLs, eine Liste von Zertifikaten) ausgestellt wurden ungültig) oder Ausführen eines OCSP-Servers (ähnlich wie CRLs, jedoch ein Onlinedienst, der den Gültigkeitsstatus für Zertifikate bereitstellt).

Die entsprechende OpenSSL-Dokumentationsseite ist für den Befehl x509 und x509v3_config

Hier ist die OpenSSL-Konfiguration, die ich zum Generieren von Client-Zertifikaten verwende:

[user]
basicConstraints = critical,CA:FALSE
extendedKeyUsage = clientAuth,emailProtection
subjectAltName=email:copy
crlDistributionPoints = URI:http://www.rgweb.org/ca/rgweb-ca.crl
authorityKeyIdentifier=keyid:always
authorityInfoAccess = caIssuers;URI:http://www.rgweb.org/ca/rgweb-ca.cer

Ich werde Sie Zeile für Zeile durchgehen:

Das basicConstraintsist als kritisch festgelegt. Dies bedeutet "Dieses Zertifikat ablehnen, wenn Sie dieses Bit nicht verstehen" und gibt an, dass das Zertifikat keine Zertifizierungsstelle ist . Selbst wenn jemand Software verwendet, um ein Zertifikat aus diesem Zertifikat auszustellen, wird ihm niemals vertraut.

Die erweiterte Verwendung von Schlüsseln ist nicht unbedingt erforderlich, für einige Software muss sie jedoch vorhanden sein und einen bestimmten Zweck haben. Hier werden die Clientauthentifizierung (wovon Sie sprechen) sowie die S / MIME-E-Mail-Signatur und -Verschlüsselung aufgeführt. Sie können den S / MIME-Zweck sicher entfernen, wenn Sie ihn nicht benötigen.

subjectAltNameMit dieser Option können Sie Informationen zu dem Thema einfügen, die Sie nicht in das subjectFeld aufnehmen können. Es wird auch in Webserverzertifikaten verwendet, um Domänennamen einzuschließen, für die das Zertifikat möglicherweise für eine andere als die im Attribut "Allgemeiner Name" des Betreffs angegebene Domäne verwendet wird. Diese Zertifikate werden als SAN-Zertifikate (Subject Alternative Name) bezeichnet. Es ist üblich, die E-Mail-Adresse subjectAltNamein den Betreff und nicht in den Betreff aufzunehmen. Sie müssen überhaupt keine E-Mail-Adresse angeben und können die Erweiterung weglassen.

crlDistributionPointslistet die Stellen auf, an denen die CRL für die ausstellende Behörde verfügbar ist; Es teilt der Software mit, die versucht, das Zertifikat zu validieren. "Hier erfahren Sie, ob dieses Zertifikat noch gültig ist." Für die Internetnutzung http://ist wahrscheinlich eine URL am besten geeignet (CRLs sind digital signiert, daher ist dies nicht erforderlich httpsund kann zu Problemen mit der Vertrauensschleife führen).

authorityKeyIdentifierist normalerweise der SHA-1-Hash des öffentlichen Schlüssels der ausstellenden Zertifizierungsstelle (obwohl es sich möglicherweise um andere Werte handelt). Wenn Sie diese Erweiterung einschließen, musssubjectKeyIdentifier der Wert mit dem Wert im ausstellenden CA-Zertifikat übereinstimmen .

authorityInfoAccessist ein bisschen wie, crlDistributionPointsaber es gibt an, wo das ausstellende CA- Zertifikat anstelle der CRL zu erhalten ist. Dies ist nützlich, wenn Sie eine lange Vertrauenskette haben: z. B. CA-1 stellt CA-2 aus, das CA-3 ausgibt, das das Zertifikat ausstellt; Software, die versucht, das Zertifikat zu überprüfen, kann diese Erweiterung verwenden, um das CA-3-Zertifikat abzurufen, und dann den Wert in diesem Zertifikat verwenden, um das CA-2-Zertifikat usw. abzurufen. Normalerweise die Zertifikatkette (in diesem Fall das CA-2-Zertifikat) und CA-3-Zertifikat) wird neben dem Zertifikat des Betreffs gebündelt (z. B. in einer SSL-Transaktion oder einer S / MIME-E-Mail). Ich kenne keine Software, die diese Erweiterung verwendet, aber ich weiß auch nicht, dass sie nicht häufig verwendet wird. Es ist häufig in Zertifikaten enthalten.

Von all dem brauchst du nur das basicConstraintsund wirklich extendedKeyUsage; Grundlegende Einschränkungen müssen wirklich kritisch sein (oder Sie haben gerade CA-Zertifikate ausgehändigt!), und eine erweiterte Schlüsselverwendung ist dies im Allgemeinen nicht.