openssl req -x509 -days 365 -newkey rsa: 2048 -keyout /etc/ssl/apache.key -out /etc/ssl/apache.crt
Mit diesem Befehl können Sie kein wohlgeformtes X.509-Zertifikat generieren. Es ist fehlerhaft, da der Hostname im Common Name (CN) steht . Das Einfügen eines Hostnamens oder einer IP-Adresse in den CN wird sowohl von der IETF (den meisten Tools wie wgetund curl) als auch von den CA / B-Foren (CAs und Browsern) nicht mehr empfohlen.
Sowohl in den IETF- als auch in den CA / B-Foren werden Servernamen und IP-Adressen immer in den alternativen Antragstellernamen (Subject Alternate Name, SAN) eingetragen . Die Regeln finden Sie in RFC 5280, Internet X.509-Zertifikat für die Infrastruktur öffentlicher Schlüssel und CRL-Profil (Certificate Revocation List) sowie in den Grundanforderungen für das CA / Browser-Forum .
Meistens müssen Sie eine OpenSSL-Konfigurationsdatei verwenden und an Ihre Bedürfnisse anpassen. Unten ist ein Beispiel von einem, das ich benutze. Es wird aufgerufen example-com.confund über an den OpenSSL-Befehl übergeben -config example-com.conf.
Auch beachten Sie auch : alle Maschinen zu behaupten localhost, localhost.localdomainetc. Seien Sie vorsichtig über die Ausstellung von Bescheinigungen für localhost. Ich sage nicht , tu es nicht; Verstehe nur, dass es einige Risiken gibt.
Folgende Alternativen localhoststehen zur Verfügung: (1) Führen Sie DNS aus und stellen Sie Zertifikate für den DNS-Namen des Computers aus. Oder (2) statische IP verwenden und die statische IP-Adresse angeben.
Die Browser geben weiterhin Warnungen zu einem selbstsignierten Zertifikat aus, das nicht mit einem vertrauenswürdigen Stamm verknüpft ist. Tools mögen curlund wgetwerden sich nicht beschweren, aber Sie müssen sich dennoch darauf verlassen, dass Sie mit einer Option wie cURL selbst signiert sind --cafile. Um das Vertrauensproblem des Browsers zu überwinden, müssen Sie Ihre eigene Zertifizierungsstelle werden.
"Ihre eigene Zertifizierungsstelle werden" wird als Ausführung einer privaten PKI bezeichnet. Da ist nicht viel dran. Sie können alles tun, was eine öffentliche Zertifizierungsstelle kann. Der einzige Unterschied besteht darin, dass Sie Ihr Root-CA-Zertifikat in den verschiedenen Geschäften installieren müssen . Es ist nicht anders als zum Beispiel mit cURLs cacerts.pm. cacerts.pmist nur eine Sammlung von Stammzertifizierungsstellen, und jetzt sind Sie dem Club beigetreten.
Wenn Sie Ihre eigene Zertifizierungsstelle werden, müssen Sie Ihren privaten Schlüssel für die Stammzertifizierungsstelle auf einen Datenträger brennen und ihn offline halten. Legen Sie es dann in Ihr CD / DVD-Laufwerk ein, wenn Sie eine Signaturanforderung signieren müssen. Jetzt stellen Sie Zertifikate wie eine öffentliche Zertifizierungsstelle aus.
Nichts davon ist fürchterlich schwierig, sobald Sie eine oder zwei Unterzeichnungsanforderungen unterschrieben haben. Ich betreibe seit Jahren eine private PKI im Haus. Alle meine Geräte und Gadgets vertrauen meiner Zertifizierungsstelle.
Weitere Informationen dazu, wie Sie Ihre eigene Zertifizierungsstelle werden , finden Sie unter Wie signieren Sie eine Zertifikatsignierungsanforderung bei Ihrer Zertifizierungsstelle und wie Sie mit openssl ein selbstsigniertes Zertifikat erstellen? .
Aus den Kommentaren in der Konfigurationsdatei unten ...
Selbst signiert (beachten Sie die Hinzufügung von -x509)
openssl req -config example-com.conf -new -x509 -sha256 -newkey rsa:2048 -nodes -keyout example-com.key.pem -days 365 -out example-com.cert.pem
Signaturanforderung (beachten Sie das Fehlen von -x509)
openssl req -config example-com.conf -new -newkey rsa:2048 -nodes -keyout example-com.key.pem -days 365 -out example-com.req.pem
Drucken Sie eine selbst signierte
openssl x509 -in example-com.cert.pem -text -noout
Drucken Sie eine Signaturanforderung aus
openssl req -in example-com.req.pem -text -noout
Konfigurationsdatei
# Self Signed (note the addition of -x509):
# openssl req -config example-com.conf -new -x509 -sha256 -newkey rsa:2048 -nodes -keyout example-com.key.pem -days 365 -out example-com.cert.pem
# Signing Request (note the lack of -x509):
# openssl req -config example-com.conf -new -newkey rsa:2048 -nodes -keyout example-com.key.pem -days 365 -out example-com.req.pem
# Print it:
# openssl x509 -in example-com.cert.pem -text -noout
# openssl req -in example-com.req.pem -text -noout
[ req ]
default_bits = 2048
default_keyfile = server-key.pem
distinguished_name = subject
req_extensions = req_ext
x509_extensions = x509_ext
string_mask = utf8only
# The Subject DN can be formed using X501 or RFC 4514 (see RFC 4519 for a description).
# It's sort of a mashup. For example, RFC 4514 does not provide emailAddress.
[ subject ]
countryName = Country Name (2 letter code)
countryName_default = US
stateOrProvinceName = State or Province Name (full name)
stateOrProvinceName_default = NY
localityName = Locality Name (eg, city)
localityName_default = New York
organizationName = Organization Name (eg, company)
organizationName_default = Example, LLC
# Use a friendly name here because it's presented to the user. The server's DNS
# names are placed in Subject Alternate Names. Plus, DNS names here is deprecated
# by both IETF and CA/Browser Forums. If you place a DNS name here, then you
# must include the DNS name in the SAN too (otherwise, Chrome and others that
# strictly follow the CA/Browser Baseline Requirements will fail).
commonName = Common Name (e.g. server FQDN or YOUR name)
commonName_default = Example Company
emailAddress = Email Address
emailAddress_default = test@example.com
# Section x509_ext is used when generating a self-signed certificate. I.e., openssl req -x509 ...
[ x509_ext ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
# If RSA Key Transport bothers you, then remove keyEncipherment. TLS 1.3 is removing RSA
# Key Transport in favor of exchanges with Forward Secrecy, like DHE and ECDHE.
basicConstraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment
subjectAltName = @alternate_names
nsComment = "OpenSSL Generated Certificate"
# RFC 5280, Section 4.2.1.12 makes EKU optional
# CA/Browser Baseline Requirements, Appendix (B)(3)(G) makes me confused
# extendedKeyUsage = serverAuth, clientAuth
# Section req_ext is used when generating a certificate signing request. I.e., openssl req ...
[ req_ext ]
subjectKeyIdentifier = hash
basicConstraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment
subjectAltName = @alternate_names
nsComment = "OpenSSL Generated Certificate"
# RFC 5280, Section 4.2.1.12 makes EKU optional
# CA/Browser Baseline Requirements, Appendix (B)(3)(G) makes me confused
# extendedKeyUsage = serverAuth, clientAuth
[ alternate_names ]
DNS.1 = example.com
DNS.2 = www.example.com
DNS.3 = mail.example.com
DNS.4 = ftp.example.com
# Add these if you need them. But usually you don't want them or
# need them in production. You may need them for development.
# DNS.5 = localhost
# DNS.6 = localhost.localdomain
# DNS.7 = 127.0.0.1
# IPv6 localhost
# DNS.8 = ::1
# DNS.9 = fe80::1
Möglicherweise müssen Sie für Chrome die folgenden Schritte ausführen. Andernfalls beschwert sich Chrome möglicherweise, dass ein allgemeiner Name ungültig ist ( ERR_CERT_COMMON_NAME_INVALID) . Ich bin nicht sicher, wie die Beziehung zwischen einer IP-Adresse im SAN und einem CN in diesem Fall ist.
# IPv4 localhost
# IP.1 = 127.0.0.1
# IPv6 localhost
# IP.2 = ::1
Centos 7 / Vagrant / Chrome Browser.