FirefoxおよびSSL：sec_error_unknown_issuer
クライアントはsec_error_unknown_issuer Firefoxで https://mediant.ipmail.nl にアクセスしたときのエラーメッセージ。エラーを自分で再現することはできません。 VistaにFFをインストールし、XPマシンで問題ありませんでした。UbuntuのFFも正常に動作します。
誰かが同じエラーを受け取り、誰かが私にいくつかの手がかりを持っているので、ISPにいくつかの設定を変更するように伝えることができますか？証明書は、すべてのサブドメイン（* .ipmail.nl）で機能する、いわゆるワイルドカードSSL証明書です。最も安いものを選ぶのは間違っていましたか？
Comodo Wildcard SSL証明書でも同じ問題が発生しました。ドキュメントを読んだ後の解決策は、送信する証明書チェーンファイルを構成に含めることです。
SSLCertificateChainFile /etc/ssl/crt/yourSERVERNAME.ca-bundle
Comodoサイト の詳細
この問題が発生し、Firefox固有のものでした。そのブラウザでのみ再現でき、Safari、IE8、Chromeなどはすべて問題ありませんでした。
修正が必要ですComodoから更新された証明書を取得とインストール。
彼らがどのような魔法を変えたかはわかりませんが、Firefoxが気に入らなかったのは間違いなく証明書の中の何かでした。
Nginxの場合、これを実行して、チェーンされたcrtファイルを生成します
$ cat www.example.com.crt bundle.crt > www.example.com.chained.crt
結果のファイルは、ssl_certificateディレクティブで使用する必要があります。
server {
listen 443 ssl;
server_name www.example.com;
ssl_certificate www.example.com.chained.crt;
ssl_certificate_key www.example.com.key;
...
}
Firefoxは他のブラウザーよりも厳格であり、中間サーバー証明書の適切なインストールが必要になります。これは、証明書の購入元の証明機関から提供されます。通常、中間証明書はサーバー証明書と同じ場所にインストールされ、httpd.confファイルに適切なエントリが必要です。
多くの人がFirefoxを（一般的に）排他的な「フラグ」として非難していますが、実際にはより高いレベルのセキュリティ標準を実証しています。
私はこのスレッドが少し古いことを知っていますが、私たちもこれに出くわし、他の人のためにここで最終的な解決策をアーカイブします。
Comodoワイルドカード「ポジティブSSL」証明書でも同じ問題が発生しました。私たちはsquid-reverse SSLプロキシを使用してWebサイトを実行していますが、Firefoxはあなたが述べたように「sec_error_unknown_issuer」と文句を言い続けますが、他のブラウザはすべて問題ありませんでした。
これは、証明書チェーンが不完全な問題であることがわかりました。 FirefoxはルートCAを信頼していますが、Firefoxには中間証明書が組み込まれていないようです。したがって、証明書のチェーン全体をFirefoxに提供する必要があります。 Comodoのサポート状態：
中間証明書は、サイト（サーバー）証明書とルート証明書の間の証明書です。中間証明書は、ブラウザが信頼するルート証明書へのチェーンを完成させます。
中間証明書を使用すると、インストールプロセスの追加手順を完了して、サイト証明書を信頼できるルートにチェーンできるようにし、誰かがWebサイトにアクセスしたときにブラウザーにエラーが表示されないようにする必要があります。
これは、このスレッドの前半ですでに触れましたが、これを行う方法は削除しませんでした。
まず、証明書チェーンのチェーンを作成する必要があります。そして、お気に入りのテキストエディターを使用して、正しい（逆の）順序で貼り付けます。
- 中間CA証明書2-IntermediateCA2.crt-ファイルの上
- 中間CA証明書1-IntermediateCA1.crt
- ルートCA証明書-root.crt-ファイルの最後
名前から明らかでない場合、SSLプロバイダーから取得できる正確な順序。
次に、ファイルを好きな名前で保存します。例えば。 yourdomain-chain-bundle.crt
この例では、実際のドメイン証明書を含めていません。サーバーが別個のチェーン証明書バンドルを取得するように構成できる限り、これは使用するものです。
より多くのデータはここで見つけることができます：
何らかの理由で別のチェーンバンドルを使用するようにサーバーを構成できない場合は、サーバー証明書をバンドルの先頭（最上部）に貼り付け、結果のファイルをサーバー証明書として使用します。これは、例えばイカの場合に行う必要があるものです。このテーマに関するsquidメーリングリストの以下を参照してください。
http://www.squid-cache.org/mail-archive/squid-users/201109/0037.html
これで解決しました。
Firefoxとサーバーでこの問題が発生しました。 GoDaddyカスタマーサポートに連絡し、中間サーバー証明書をインストールしてもらいました。
http://support.godaddy.com/help/article/868/what-is-an-intermediate-certificate
World Wide Web発行サービスの再開後、すべてが完全に機能しました。
サーバーへの完全なアクセス権がない場合は、ISPがこれを行う必要があります。
クライアントはどのプラットフォームでどのバージョンのFirefoxを使用していますか？
文書化されたものと同じ問題を抱えている人々 ここではFirefoxのサポートフォーラム 。そこで解決策が見つかることを願っています。幸運を！
更新：
クライアントがFirefoxの設定を確認できるようにします。[詳細設定]-[暗号化]に[証明書の表示]ボタンがあります。 リストで「Comodo CA Limited」を探します。 Comodoはそのドメイン名/サーバーの証明書の発行者であることがわかりました。 2台のマシン（VistaおよびMacの場合はFF 3.0.3）では、エントリはリストにあります（デフォルト/ Mozilla）。
COMODOから証明書を取得し、この行を追加する必要がある場合、ファイルは受け取ったZipファイルにあります。
SSLCertificateChainFile /path/COMODORSADomainValidationSecureServerCA.crt
2014年6月：
これは私が使用した構成で、数日間壁に頭をぶつけた後でも正常に機能します。 Express 3.4を使用します（Express 4.0でも同じだと思います）
var privateKey = fs.readFileSync('helpers/sslcert/key.pem', 'utf8');
var certificate = fs.readFileSync('helpers/sslcert/csr.pem', 'utf8');
files = ["COMODORSADomainValidationSecureServerCA.crt",
"COMODORSAAddTrustCA.crt",
"AddTrustExternalCARoot.crt"
];
ca = (function() {
var _i, _len, _results;
_results = [];
for (_i = 0, _len = files.length; _i < _len; _i++) {
file = files[_i];
_results.Push(fs.readFileSync("helpers/sslcert/" + file));
}
return _results;
})();
var credentials = {ca:ca, key: privateKey, cert: certificate};
// process.env.PORT : Heroku Config environment
var port = process.env.PORT || 4000;
var app = express();
var server = http.createServer(app).listen(port, function() {
console.log('Express HTTP server listening on port ' + server.address().port);
});
https.createServer(credentials, app).listen(3000, function() {
console.log('Express HTTPS server listening on port ' + server.address().port);
});
// redirect all http requests to https
app.use(function(req, res, next) {
if(!req.secure) {
return res.redirect(['https://mydomain.com', req.url].join(''));
}
next();
});
次に、80ポートと443ポートをリダイレクトしました。
Sudo iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-ports 4000
Sudo iptables -t nat -A PREROUTING -p tcp --dport 443 -j REDIRECT --to-ports 3000
あなたが私の認定をチェックした後に見ることができるように、私は4 [0,1,2,3]を持っています：
openssl s_client -connect mydomain.com:443 -showcerts | grep "^"
ubuntu@ip-172-31-5-134:~$ openssl s_client -connect mydomain.com:443 -showcerts | grep "^ "
depth=3 C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust External CA Root
verify error:num=19:self signed certificate in certificate chain
verify return:0
0 s:/OU=Domain Control Validated/OU=PositiveSSL/CN=mydomain.com
i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA
1 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA
i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority
2 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority
i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
3 s:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
Protocol : TLSv1.1
Cipher : AES256-SHA
Session-ID: 8FDEAEE92ED20742.....3E7D80F93226142DD
Session-ID-ctx:
Master-Key: C9E4AB966E41A85EEB7....4D73C67088E1503C52A9353C8584E94
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
0000 - 7c c8 36 80 95 4d 4c 47-d8 e3 ca 2e 70 a5 8f ac |.6..MLG....p...
0010 - 90 bd 4a 26 ef f7 d6 bc-4a b3 dd 8f f6 13 53 e9 ..J&..........S.
0020 - f7 49 c6 48 44 26 8d ab-a8 72 29 c8 15 73 f5 79 .I.HD&.......s.y
0030 - ca 79 6a ed f6 b1 7f 8a-d2 68 0a 52 03 c5 84 32 .yj........R...2
0040 - be c5 c8 12 d8 f4 36 fa-28 4f 0e 00 eb d1 04 ce ........(.......
0050 - a7 2b d2 73 df a1 8b 83-23 a6 f7 ef 6e 9e c4 4c .+.s...........L
0060 - 50 22 60 e8 93 cc d8 ee-42 22 56 a7 10 7b db 1e P"`.....B.V..{..
0070 - 0a ad 4a 91 a4 68 7a b0-9e 34 01 ec b8 7b b2 2f ..J......4...{./
0080 - e8 33 f5 a9 48 11 36 f8-69 a6 7a a6 22 52 b1 da .3..H...i....R..
0090 - 51 18 ed c4 d9 3d c4 cc-5b d7 ff 92 4e 91 02 9e .....=......N...
Start Time: 140...549
Timeout : 300 (sec)
Verify return code: 19 (self signed certificate in certificate chain)
幸運を！ PD：さらに回答が必要な場合は、以下を確認してください： http://www.benjiegillam.com/2012/06/node-dot-js-ssl-certificate-chain/
@ user126810が言ったように、問題は設定ファイルの適切なSSLCertificateChainFileディレクティブで修正できます。
しかし、構成を修正してWebサーバーを再起動した後、Firefoxを再起動する必要もありました。それがなければ、Firefoxは不正な証明書について文句を言い続けました（キャッシュされた証明書を使用したようです）。
Ubuntu LAMPと「COMODO Positive SSL」でこの問題が発生している人がいる場合は、圧縮ファイル内の証明書から独自のバンドルを構築してください。
cat AddTrustExternalCARoot.crt COMODORSAAddTrustCA.crt COMODORSADomainValidationSecureServerCA.crt > YOURDOMAIN.ca-bundle
Firefox 43、El Capitan、およびWHM/cPanel SSLのインストールで、信頼できないサイトのエラーを継続的に取得している-私は最後の男がドアを出たときにインストールするために私に渡された証明書を購入しませんでした。 wwwを見逃したため間違ったドメインにインストールしていたことが判明しました-しかし、www.domain.com.auを使用してWHMに証明書をインストールすると、証明書がドメインに対してインストールされたままになり、心配してFFエラーがなくなりました-証明書はwwwとwww以外の両方で正常に機能します。
質問の非再現性の側面に答えるために-Firefoxは中間証明書を証明書ストアに自動的にインポートします。したがって、以前に正しく構成された証明書チェーンを使用して同じ中間証明書を使用したサイトにアクセスしたことがある場合、Firefoxはその証明書を保存するため、同じ中間物を使用してチェーンが正しく構成されていないサイトにアクセスしても問題は発生しません証明書。
これは、Firefoxの証明書マネージャー（オプション->プライバシーとセキュリティ->証明書の表示...）で確認でき、保存されているすべての証明書を確認できます。 「セキュリティデバイス」列で、証明書の出所を確認できます。Firefoxでインストールされるデフォルトのセットである「ビルトインオブジェクトトークン」ではなく、自動/手動でインポートされた証明書が「ソフトウェアセキュリティデバイス」から表示されます。特定の証明書を削除/信頼しないで、再度テストできます。