Issue metadata
Sign in to add a comment
|
adding www.commercialpassport.net EV SSL to CT log
Reported by
servi...@commercialpassport.com,
Mar 31 2016
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:44.0) Gecko/20100101 Firefox/44.0 Steps to reproduce the problem: 1. Open Chrome 2. Navigate to https://www.commercialpassport.net/ 3. Chrome doesn't show greenbox in address bar for that EV SSL What is the expected behavior? Chrome should show greenbox in address bar after adding www.commercialpassport.net to CT log What went wrong? Chrome doesnt show EV SSL for https://www.commercialpassport.net/ Did this work before? N/A Chrome version: 49.0.2623.87 m Channel: n/a OS Version: 6.3 Flash Version: Contact: - email: services@commercialpassport.com - phone: +380634567878 - contact person: Andrew Greeen Public Key: www.commercialpassport.net.crt attached Accepted Roots: www.commercialpassport.net.root.crt attached The private key is secured and hosted in safeswisscloud.ch
,
Mar 31 2016
WontFix/WorkingAsIntended. Note: The status of EV or not is dependent on whether or not Signed Certificate Timestamps were provided on the connection. The act of adding it to a log results in an SCT from that log. However, you need to log into enough logs to obtain SCTs that meet the requirements set forth at https://www.chromium.org/Home/chromium-security/certificate-transparency (under EV/CT Plan) While you have logged the certificate in at least one log, you need to serve the SCTs on the connection. There are three options (all of which can be used, even simultaneously) to do this - one which only the issuing CA can do, one which requires cooperation of the issuing CA and the site, and one which only the site can do. This is covered in the CT specification (RFC 6962), but repectably are: 1) Deliver the SCTs embedded in the certificate (the CA is expected to do this) 2) Deliver the SCTs embedded in the OCSP response (the CA creates the OCSP response, but as a server operator, you need to support OCSP stapling and staple fresh OCSP responses to all connections) 3) Deliver the SCTs via a TLS extension (covered in 6962) Because Swisssign is not doing either 1 or 2, you're not getting the EV status, and that's Working as Intended, in line with our policies for the recognition of EV certificates. In order to get EV treatment, your servers would need to support the SCT TLS extension, and deliver such SCTs on the connection. That's out of scope for the Chromium bug tracker, because it's specific to your serving infrastructure, but you can find additional information and links to forums where you may find support at http://www.certificate-transparency.org/
,
Apr 5 2016
Hello. Thanks for your reply. Have i understood correctly, that the only way to fix mentioned problem - is configure nginx on web-server with https://github.com/grahamedgecombe/nginx-ct module? Is there any other chances fix the problem from SwissSign side? As i see their site https://www.swisssign.com/ has similar SSL but it is correct in chrome. Please advice.
,
Apr 5 2016
That sounds correct, based on the certificate you have. For any other issues, you'll need to contact SwissSign, as this problem is their fault.
,
Sep 22 2016
,
Sep 22 2016
,
Oct 1 2016
This bug has been closed for more than 14 weeks. Removing security view restrictions. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 2 2016
This bug has been closed for more than 14 weeks. Removing security view restrictions. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 2 2016
|
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by penny...@chromium.org
, Mar 31 2016Labels: -OS-Windows OS-All
Owner: rsleevi@chromium.org