Windows/Linuxの混合環境で、Ubuntu 16.04サーバーと内部リソース用のOpenSSLバックエンドを搭載した内部認証局を実行します。
このCAは、内部Webサイト、ソフトウェア展開などに有効で信頼できるサイト証明書を提供する目的で、一部の内部Webサイトで使用されます。1つの問題があります。
CAルート証明書は、GPOによってすべてのWindowsシステムにプッシュされるか、手動でインストールされました。ただし、そのCAによって署名されたすべての証明書は最終的にいくつかの問題を引き起こします-ChromeおよびFirefoxは両方とも、証明書に無効な共通名があることを示していますが、XMPPサーバーなどの他のユーティリティは検証できませんCA証明書がトラストストアにある場合でも、証明書。
Internet Explorerのみが証明書を尊重します。残念ながら、私たちはChromeおよびFirefoxの家なので、IEをすべてに使用すると問題が発生します。
OpenSSL CA証明書と発行済み証明書の署名済み証明書を作成するための解決策を誰かが考え出しましたnot ChromeおよびFirefoxで「無効な一般名」エラーが発生し、したがって、内部証明書を「有効」と見なすことを許可しますか?
私は実際に核心的な問題を見つけました、そしてそれは検索のトンを要しました。最後に見つかりました StackOverflowの回答 。これは、証明書自体の実際のデータの調査とopenssl req -text -noout -verify -in CSR.csr
を使用してCSRのデータを読み取り、openssl x509 -in certificate.crt -text -noout
を分析して結合しました生成された証明書とこれら2つを比較して、コアの問題を指摘しました。
どうやら、OpenSSLはV3拡張機能に関連する構成ファイルのセクションを無視しており、あなたがtell実際のCA署名ステップで適切にそれを伝えます...
これは、openssl req
コマンドに渡される構成ファイルのデータです。
[ req ]
default_bits = 4096
Prompt = no
default_md = sha256
distinguished_name = dn
req_extensions = v3_req
[ dn ]
C=US
ST=Pennsylvania
L=Somewhere
O=No Man's Land
OU=Internal
CN = chat.foo.bar.baz
[ v3_req ]
keyUsage = keyEncipherment, dataEncipherment
extendedKeyUsage=serverAuth
subjectAltName = @alt_names
[alt_names]
DNS.1 = chat.foo.bar.baz
DNS.2 = chat
DNS.3 = 10.1.2.151
次の標準呼び出しは、v3拡張機能を何らかの方法で尊重しませんでした。
openssl req -new -sha256 -out cert.csr -key cert.key -config csrgen.cnf
...しかし、これはうまくいきました:
openssl req -new -sha256 -out cert.csr -key cert.key -config csrgen.cnf -extensions v3_req
...そして、CAで証明書に署名するときは、次のようなものを使用する必要があり、すべてのサイト証明書(CSRとキーを含む)が格納されている場所からこれを実行します。そもそも証明書を生成するため-CA証明書とキーは、システムの別の/certauthority/...
セクションにあります):
openssl x509 -req -days 3650 -in ./cert.csr -CA /certauthority/certs/cacert.pem -CAkey /certauthority/private/cakey.pem -CAserial /certauthority/CA/serial -CAcreateserial -out certificate.crt -extfile csrgen.cnf -extensions v3_req
このコマンドは、v3拡張機能を証明書に適切に配置し、そうでなければファイルの実際の拡張機能を何らかの方法で無視しました。これにより、CNおよびSAN問題が解決され、システムは内部サイトおよび(ほとんどの)内部サービスに対して「有効」として証明書を返します。