<story><title>Chromium and Mozilla to enforce 1 year validity for TLS certificates</title><url>https://chromium.googlesource.com/chromium/src/+/ae4d6809912f8171b23f6aa43c6a4e8e627de784</url></story><parent_chain><item><author>elcritch</author><text>It’s a glaring security hole, IMHO. I create such devices and the only way I know is self-signed certs, but the browsers complain a lot about that. Ideally there’d be a way to sign .local domains with browsers handling it while letting people know to verify the identity of their local devices&amp;#x2F;services and that the identity isn’t verified by https like most sites.&lt;p&gt;The issue lies between the browsers and https system. SSH can do encryption without requiring identity verification. It handles it by asking &amp;quot;Do you want to trust this new server?&amp;quot;. Then if it changes informs you of that. Browsers could easily implement that for .local with self-signed certs.&lt;p&gt;Of course browser developers assume everyone has internet all the time and you only access servers with signed domains. I’ve wondered what it’d take to get an ITEF&amp;#x2F;W3C RFQ published for .local self-signed behavior.&lt;p&gt;(Edit: RFQ, not my autocomplete’s RTF)</text></item><item><author>paledot</author><text>With the tightening of certificate trust, demise of self-signed certificates, etc., is there any remaining way to establish a consumer-oriented HTTPS server on a local network? Thinking of things like routers, printers, and self-hosted IoT devices here. Some of the label printers we support at work have simply atrocious workarounds to get them to work, and I&amp;#x27;m wondering if it&amp;#x27;s the manufacturer&amp;#x27;s fault or if that use case has been completely abandoned in the push for tighter security on the Internet.</text></item></parent_chain><comment><author>akira2501</author><text>&amp;gt;  Ideally there’d be a way to sign .local domains with browsers handling it while letting people know to verify the identity of their local devices&amp;#x2F;services and that the identity isn’t verified by https like most sites.&lt;p&gt;For these types of sites we run a local CA,  and sign regular certificates for these domains and then distribute the CA certificate to our windows clients through a GPO.  When put into the correct store,  all our &amp;quot;locally-signed&amp;quot; certificates show as valid.&lt;p&gt;In other instances,  where I haven&amp;#x27;t been able to do that,  like for disparate VPN clients and such I will generally assign a RFC1918 address to it.  Like service.vpn.ourdomain.com resolves to 10.92.83.200.  As long as I can respond to a DNS challenge,  I can still get a letsencrypt certificate for that domain.</text></comment>
<story><title>Chromium and Mozilla to enforce 1 year validity for TLS certificates</title><url>https://chromium.googlesource.com/chromium/src/+/ae4d6809912f8171b23f6aa43c6a4e8e627de784</url></story><parent_chain><item><author>elcritch</author><text>It’s a glaring security hole, IMHO. I create such devices and the only way I know is self-signed certs, but the browsers complain a lot about that. Ideally there’d be a way to sign .local domains with browsers handling it while letting people know to verify the identity of their local devices&amp;#x2F;services and that the identity isn’t verified by https like most sites.&lt;p&gt;The issue lies between the browsers and https system. SSH can do encryption without requiring identity verification. It handles it by asking &amp;quot;Do you want to trust this new server?&amp;quot;. Then if it changes informs you of that. Browsers could easily implement that for .local with self-signed certs.&lt;p&gt;Of course browser developers assume everyone has internet all the time and you only access servers with signed domains. I’ve wondered what it’d take to get an ITEF&amp;#x2F;W3C RFQ published for .local self-signed behavior.&lt;p&gt;(Edit: RFQ, not my autocomplete’s RTF)</text></item><item><author>paledot</author><text>With the tightening of certificate trust, demise of self-signed certificates, etc., is there any remaining way to establish a consumer-oriented HTTPS server on a local network? Thinking of things like routers, printers, and self-hosted IoT devices here. Some of the label printers we support at work have simply atrocious workarounds to get them to work, and I&amp;#x27;m wondering if it&amp;#x27;s the manufacturer&amp;#x27;s fault or if that use case has been completely abandoned in the push for tighter security on the Internet.</text></item></parent_chain><comment><author>paledot</author><text>I love this idea. There are enough influential tech people who read HN, can we make this happen please?</text></comment>