Open renandincer opened 8 years ago
zackbloom
commented
8 years ago The second issue sounds much more serious than the first. If we can't include a universal wildcard, we probably need vee to generate the certs on demand, by calling out to OpenSSL via https://www.npmjs.com/package/openssl-wrapper or the like.
renandincer
commented
8 years ago This issue has been there for a while. While development Chrome can be set to ignore insecure connection warnings. It's only a problem when trying to set up a ssl connection without any warnings whatsoever.
This is why I think a more complicated solution (involving locally generated certificates and prompting users to trust these certificates manually using their os/browser dependent certificate manager) is a big undertaking — especially since these tools change constantly nowadays.
Maybe a simple explanation of the problem in the readme and links to resources is the best way to communicate this.
Sites with end-entity certificates that expire on or after 1 January 2017, and which include a SHA-1-based signature as part of the certificate chain is treated as “affirmatively insecure”
Also, it looks like chrome also checks for the CN on the certificate, which makes it harder to issue a wildcard certificate that covers all needs.
This renders using Vee's supplied certificate as a real ssl certificate (without bypassing security warnings) hard if not impossible.
https://security.googleblog.com/2014/09/gradually-sunsetting-sha-1.html https://www.entrust.com/chrome-shows-ssl-warning-non-fqdn/