Certificate error with missing intermediate certs on high Sierra
Reported by
exhut...@gmail.com,
Jul 12
|
||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36 Example URL: https://vdcs.thu.edu.tw Steps to reproduce the problem: 1. visit the website https://vdcs.thu.edu.tw 2. then click "VMware Horizon HTML Access" 3. login with the credential: username: vmware_support password: 3022130221 4. after login the portal, click one virtual desktop application, for example the (Ubuntu-02). 5. during the launching process, it will prompt the error of "Your connection is not private". see the picture certificate_error.png What is the expected behavior? no certificate error and virtual desktop launching is successful What went wrong? the certifcate chain of the website, see the picture certifcate_chain.png: TWCA Root Certification Authority 1 TWCA Global Root CA TWCA Secure SSL Certifcation Authority *.thu.edu.tw Check the "Keychain Access" of macOS, it only contains the "TWCA Root Certification Authority” & "TWCA Global Root CA", but missing the imtermediate certificate "TWCA Secure SSL Certifcation Authority". see the picture certificate_keychain.png So the *.thu.edu.tw" is not trusted. If manually import the imtermediate certificate to the the Keychain, there is no certificate error any more. and virtual desktop could be successfully launched. Does it occur on multiple sites: N/A Is it a problem with a plugin? N/A Did this work before? N/A Does this work in other browsers? N/A Chrome version: 67.0.3396.99 Channel: stable OS Version: 10.13 Flash Version: the problem also happens in Safari. But not happen in Windows platform and masOS lower than 10.11
,
Jul 12
Marking as WontFix, as this isn't a Chrome issue. 1) The server is "misconfigured", in that it should send the intermediate as part of the TLS handshake so that clients don't have to fetch it or install it. Reconfiguring how the server sends its TLS certificate (you don't need to replace it) would resolve this. 2) TWCA is violating a "SHOULD" of RFC 5280, 4.2.2.1 ( https://tools.ietf.org/html/rfc5280#section-4.2.2.1 ), in that the contents of the caIssuers of the authorityInfoAccess of the server's certificate - that is, for the certificate https://crt.sh/?id=23653064 the URL is http://sslserver.twca.com.tw/cacert/secure_sha2_2014.crt - is not DER encoded. As RFC 5280 calls out, clients are only expected to support the application/pkix-cert mime-type and DER-encoded certificates, so sending it as they are doing (as PEM) is called out as known to cause compatibility issues. |
||
►
Sign in to add a comment |
||
Comment 1 by dtapu...@chromium.org
, Jul 12