openssl req -x509 -days 365 -newkey rsa：2048 -keyout /etc/ssl/apache.key -out /etc/ssl/apache.crt
このコマンドを使用して、整形式のX.509証明書を生成することはできません。ホスト名がCommon Name（CN）に配置されているため、不正な形式になります。CNにホスト名またはIPアドレスを配置することは、IETF（wgetおよびなどのほとんどのツールcurl）とCA / Bフォーラム（CAおよびブラウザー）の両方によって非推奨になりました。
IETFフォーラムとCA / Bフォーラムの両方によると、サーバー名とIPアドレスは常にサブジェクト代替名（SAN）に入ります。ルールについては、RFC 5280、インターネットX.509公開キー基盤の証明書と証明書失効リスト（CRL）プロファイル、およびCA / Browserフォーラムのベースライン要件を参照してください。
ほとんどの場合、OpenSSL構成ファイルを使用して、ニーズに合わせて調整する必要があります。以下は私が使用するものの例です。と呼ばexample-com.confれ、OpenSSLコマンドに渡されます-config example-com.conf。
また、十分に注意してください：すべてのマシンがあると主張するlocalhost、localhost.localdomainなどのために証明書を発行するには注意してくださいlocalhost。アイムありませんと言っているのではありません。いくつかのリスクが伴うことを理解してください。
に代わるもの localhost、次のとおりです。マシンのDNS名に（1）の実行DNSと問題の証明書。または、（2）静的IPを使用し、静的IPアドレスを含めます。
ブラウザは、信頼されたルートにチェーンバックしない自己署名証明書に関する警告を引き続き表示します。以下のようなツールcurlとはwget文句はありませんが、あなたはまだ自己のcURLのようなオプションで署名あなたを信頼する必要があります--cafile。ブラウザの信頼の問題を克服するには、独自のCAになる必要があります。
「独自のCAになる」ことは、プライベートPKIの実行として知られています。大したことはありません。パブリックCAでできることはすべて実行できます。異なる唯一のものは、あなたがインストールする必要がありますです、あなたの様々な店舗でルートCA証明書を。たとえば、cURLを使用することと同じですcacerts.pm。cacerts.pmはルートCAの単なるコレクションであり、クラブに参加しました。
独自のCAになった場合は、ルートCA秘密キーをディスクに書き込み、オフラインのままにしてください。次に、署名要求に署名する必要があるときに、CD / DVDドライブにポップします。これで、パブリックCAと同じように証明書を発行できます。
1つまたは2つの署名要求に署名すると、これはそれほど難しくありません。私は何年も家でプライベートPKIを運営しています。すべてのデバイスとガジェットがCAを信頼しています。
独自のCAになるための詳細については、「証明機関で証明書署名要求に署名する方法」および「opensslで自己署名証明書を作成する方法」を参照してください。。
以下の構成ファイルのコメントから...
自己署名（-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
署名リクエスト（-x509がないことに注意してください）
openssl req -config example-com.conf -new -newkey rsa:2048 -nodes -keyout example-com.key.pem -days 365 -out example-com.req.pem
自己署名を印刷する
openssl x509 -in example-com.cert.pem -text -noout
署名リクエストを印刷する
openssl req -in example-com.req.pem -text -noout
構成ファイル
# 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
Chromeで次の操作を行う必要がある場合があります。そうしないと、ChromeはCommon Name is invalid（ERR_CERT_COMMON_NAME_INVALID）を訴えます。SANのIPアドレスとこのインスタンスのCNの関係がわからない。
# IPv4 localhost
# IP.1 = 127.0.0.1
# IPv6 localhost
# IP.2 = ::1
Centos 7 / Vagrant / Chrome Browser。