Firefox 및 SSL : sec_error_unknown_issuer
내 클라이언트는 Firefox로 https://mediant.ipmail.nl 을 sec_error_unknown_issuer
방문 할 때 오류 메시지를 받습니다 . 직접 오류를 재현 할 수 없습니다. Vista와 XP 시스템에 FF를 설치했는데 문제가 없었습니다. 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 파일에 적절한 항목이 필요합니다.
많은 사람들이 파이어 폭스를 (일반적으로) 독점적 인 '플래 깅'으로 욕하고 있지만 실제로는 더 높은 수준의 보안 표준을 보여주고 있습니다.
이 스레드가 조금 오래되었다는 것을 알고 있지만 우리는 이것도 만났고 다른 사람들을 위해 여기에 최종 솔루션을 보관할 것입니다.
Comodo 와일드 카드 "positive ssl"인증서에도 동일한 문제가 발생했습니다. 우리는 squid-reverse SSL 프록시를 사용하여 웹 사이트를 운영하고 있으며 Firefox는 귀하가 언급 한대로 "sec_error_unknown_issuer"라고 계속 불평하지만 다른 모든 브라우저는 괜찮습니다.
이것이 인증서 체인이 불완전한 문제라는 것을 알았습니다. Firefox는 루트 CA를 신뢰하지만 Firefox에는 중간 인증서 중 하나가 내장되어 있지 않습니다. 따라서 Firefox에 전체 인증서 체인을 제공해야합니다. Comodo의 지원 상태 :
중간 인증서는 사이트 (서버) 인증서와 루트 인증서 사이를 이동하는 인증서 또는 인증서입니다. 중간 인증서 또는 인증서는 브라우저에서 신뢰하는 루트 인증서에 대한 체인을 완성합니다.
중간 인증서를 사용한다는 것은 사이트 인증서를 신뢰할 수있는 루트에 연결하고 누군가 웹 사이트를 방문 할 때 브라우저에 오류가 표시되지 않도록하려면 설치 프로세스에서 추가 단계를 완료해야 함을 의미합니다.
이것은이 스레드의 앞부분에서 이미 다루었지만이를 수행하는 방법을 변경하지는 않았습니다.
먼저 연결된 인증서 번들을 만들어야하며 좋아하는 텍스트 편집기를 사용하여이를 수행하고 올바른 (역방향) 순서로 붙여 넣습니다.
- 중간 CA 인증서 2-IntermediateCA2.crt-파일 상단
- 중간 CA 인증서 1-IntermediateCA1.crt
- 루트 CA 인증서-root.crt-파일 끝
이름에서 명확하지 않은 경우 SSL 공급자로부터 얻을 수있는 정확한 순서.
그런 다음 원하는 이름으로 파일을 저장합니다. 예 : yourdomain-chain-bundle.crt
이 예에서는 실제 도메인 인증서를 포함하지 않았으며 서버가 별도의 체인 인증서 번들을 사용하도록 구성 할 수있는 한 이것이 사용하는 것입니다.
더 많은 데이터는 여기에서 찾을 수 있습니다.
어떤 이유로 별도의 체인 번들을 사용하도록 서버를 구성 할 수없는 경우 번들의 시작 부분 (상단)에 서버 인증서를 붙여넣고 결과 파일을 서버 인증서로 사용합니다. 이것은 Eg 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 Publishing 서비스를 다시 시작한 후 모든 것이 완벽하게 작동했습니다.
서버에 대한 전체 액세스 권한이없는 경우 ISP에서이 작업을 수행해야합니다.
클라이언트가 사용하는 플랫폼의 Firefox 버전은 무엇입니까?
Firefox 지원 포럼에 설명 된 것과 동일한 문제가있는 사람들 입니다. 거기에서 해결책을 찾을 수 있기를 바랍니다. 행운을 빕니다!
최신 정보:
클라이언트가 Firefox에서 설정을 확인하도록합니다. "고급"- "암호화"에 "인증서보기"버튼이 있습니다. 목록에서 "Comodo CA Limited" 를 찾으십시오 . Comodo가 해당 도메인 이름 / 서버의 인증서 발급자임을 확인했습니다. 내 컴퓨터 두 대 (Vista 및 Mac의 경우 FF 3.0.3)에서 항목이 목록에 있습니다 (기본적으로 / Mozilla).
@ user126810이 말했듯 SSLCertificateChainFile
이 구성 파일 의 적절한 지시문으로 문제를 해결할 수 있습니다 .
그러나 구성을 수정하고 웹 서버를 다시 시작한 후 Firefox 도 다시 시작 해야했습니다 . 그것없이 Firefox는 잘못된 인증서에 대해 계속해서 불평했습니다 (캐시 된 인증서를 사용한 것처럼 보입니다).
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/을 확인하십시오.
If anyone else is experiencing this issue with an Ubuntu LAMP and "COMODO Positive SSL" try to build your own bundle from the certs in the compressed file.
cat AddTrustExternalCARoot.crt COMODORSAAddTrustCA.crt COMODORSADomainValidationSecureServerCA.crt > YOURDOMAIN.ca-bundle
I've being going round in circles with Firefox 43, El Capitan and WHM/cPanel SSL installation continually getting the Untrusted site error - I didn't buy the certificate it was handed over to me to install as the last guy walked out the door. Turns out I was installing under the wrong domain because I missed off the www - but the certificate still installed against the domain, when I installed the certificate in WHM using www.domain.com.au it installed now worries and the FF error has gone - the certificate works fine for both www and non-www.
To answer the non-reproducability aspect of the question - Firefox automatically imports intermediate certificates into its certificate store. So if you've previously visited a site which has used the same Intermediate Certificate using a correctly configured certificate chain then Firefox will store that Certificate so you will not see the problem when you visit a site that has an incorrectly configured chain using the same Intermediate certificate.
You can check this in Firefox's Certificate Manager (Options->Privacy&Security->View Certificates...) where you can see all stored certificates. Under the 'Security Device' Column you can check where a certificate has come from - automatically/manually imported certificates will appear as from 'Software Security Device' as opposed to the 'Builtin Object Token', which are the default set installed with Firefox. You can delete/Distrust any specific certificates and test again.
Had same issue this end of week, only Firefox will not accept certificate... The solution for me has been to add, in the apache configuration of the website, the intermediate certificate with the following line :
SSLCACertificateFile /your/path/to/ssl_ca_certs.pem
Find more infomration on https://httpd.apache.org/docs/2.4/fr/mod/mod_ssl.html
참고URL : https://stackoverflow.com/questions/275878/firefox-and-ssl-sec-error-unknown-issuer
'Development Tip' 카테고리의 다른 글
Python 유니 코드 동등 비교 실패 (0) | 2020.12.12 |
---|---|
정적 코드 분석 도구 선택 (0) | 2020.12.12 |
기본 제공 검색 / 필터 상자를 사용하지 않고 jqGrid 데이터를 필터링하는 방법 (0) | 2020.12.12 |
핸들 바-부분적으로 부모 컨텍스트에 액세스 할 수 있습니까? (0) | 2020.12.12 |
float 컬렉션에 대한 Python 단위 테스트의 assertAlmostEqual (0) | 2020.12.12 |