web-dev-qa-db-ja.com

自宅のサーバー用のopensslがあり、ドメイン名がない自己署名証明書

私がオンラインで読んだすべての記事は、あなたが所有するドメインの自己署名証明書の作成について語っています。

自宅のUbuntu16.04サーバーにApache2をセットアップしています。私のISPは動的IPを提供するので、No-IPを使用します。トラフィックをサーバーにリダイレクトするために、ルーターでポートを開いています。

また、自宅（ネットワーク内）からWebサーバーにアクセスします。

したがって、ホームネットワークの外部にいる場合は https://username.noip.me/ を使用し、自宅にいる場合は https：// homeserver / を使用します。 =。

では、この状況で自己署名証明書を作成するにはどうすればよいですか？通称は何ですか？

sslhttpsopenssldynamic-dns
5
IMTheNachoMan

通称は何ですか？

共通名（CN）にわかりやすい名前を使用する理由は2つあります。まず、ツールによってユーザーに表示されるため、Example Widgets、LLCのようなものが必要です。次に、ホスト名常にがサブジェクト代替名（SAN）に含まれます。 CNにホスト名を配置することは、IETFフォーラムとCA/Bフォーラムの両方で非推奨になっています。

その他のルールと理由については、 認証局で証明書署名要求に署名する方法 および opensslを使用して自己署名証明書を作成する方法 を参照してください。

では、この状況で自己署名証明書を作成するにはどうすればよいですか？

カスタム構成ファイルでopensslユーティリティを使用します。以下はサンプルです。

あなたは2つのことをすべきです。まず、DNS名リストをusername.noip.meおよびhomeserverに変更します。次に、証明書で必要な名前を変更した後、次のコマンドを実行します。

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

もちろん、構成ファイルの名前はexample-com.confから任意の名前に変更できます。

また、家では自分でPKIを実行しています。必要に応じてネットワーク上のデバイスの証明書を発行するルートCAがあります。すべてのデバイスにルートCAがインストールされています。私の内部ドメインはhome.pvtと呼ばれています。ネットワーク上のホストには、pine64.home.pvt、rpi3.home.pvt、solaris.home.pvt、windows10.home.pvtなどの名前が付けられています。すべてが期待どおりに機能します。

設定ファイルの例

# 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).
#   Its 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 its 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        = [email protected]

# Section x509_ext is used when generating a self-signed certificate. I.e., openssl req -x509 ...
#  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.
[ x509_ext ]

subjectKeyIdentifier        = hash
authorityKeyIdentifier  = keyid,issuer

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
3
jww

実際の質問に答えるには：

サブジェクト代替名を確認する必要があります。

これらにより、証明書に複数のドメイン名を割り当てることができます。

共通名を空のままにして、サブジェクト代替名にすべてのFQDNをリストすることをお勧めします。

または、いずれかの名前を共通名に配置することもできますが、それらすべてをサブジェクト代替名にリストする必要があります。

2
garethTheRed

ドメイン名に10ドル以下を費やし、無料の Let's Encrypt 証明書を使用することをお勧めします。問題が少なくなります。そのnoip.meドメインを使用して証明書を取得できる場合もあります。

Let's Encryptは、Apache/Nginxを使用してサポートされているLinuxディストリビューションでセットアップするのは非常に簡単ですが、使用しているOSについてはまだ述べていません。上記の投稿を編集すると、さらにガイダンスを提供できる場合があります。

1
Tim

トリックを適用して、「*。noip.com」にワイルドカード証明書を使用できます。

これには、「homeserver.noip.com」を使用し、そのアドレスがローカルIPを指すようにする必要があります。これは、「homeserver.noip.com」を使用するマシンのhostsファイルにエントリを追加することで実行できます。

'username.noip.com'は、通常の方法で解決されます。

これはやや「汚いアプローチ」ですが、ニーズには効率的に見えます。

1
le_top