News for hackers. Stuff that matters.

A comment on Chromium and Mozilla to enforce 1 year validity for TLS certificates. Parent comment

Re:Chromium and Mozilla to enforce 1 year validity for TLS c... by akira2501 on Sunday June 28, 2020 @05:32PM (#23672237)
> 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/services and that the identity isn’t verified by https like most sites.

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 "locally-signed" certificates show as valid.

In other instances, where I haven'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.

[ Parent | on HN ]
Re:Chromium and Mozilla to enforce 1 year validity for TLS c... by johntash on Sunday June 28, 2020 @05:49PM (#23672356)
> In other instances, where I haven'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.

This is basically what I've been doing lately as well. I'll create a wildcard letsencrypt cert for .vpn.ourdomain.com and then point the subdomains to internal IPs. You can even set up a split-dns where it responds to the challenge txt records for letsencrypt, but only the internal side responds to requests under .vpn.ourdomain.com.

[ Parent | on HN ]
Re:Chromium and Mozilla to enforce 1 year validity for TLS c... by elcritch on Sunday June 28, 2020 @05:46PM (#23672334)
That works if you have control over the device/network. IoT devices usually don’t work that way. It’d be nice to be able to ensure the passcode to the device isn’t broadcast in clear http.
[ Parent | on HN ]