Hacker News Reader

Comment by zephod | Hacker News Reader

I took over a domain which had previously 301-redirected HTTP:// to HTTPS://. It caused us no end of trouble getting the alpha site online -- obviously we set up SSL but we didn't realise it was the _first thing we'd have to do_.

It also caused half a day of confusion to understand why some of our web browsers were still failing to connect and others could see the alpha site (because they'd never visited the previous 301 site at that address).

View on HN

This isn't just a problem with things like HTTP. The industry as a whole lacks a standard uniform way of dealing with domain transfers or expiration. CAs for example will happily issue certificates that expire after your domain.

It's not the CA's job to make sure your domain isn't expiring. It's yours.

I mean, would it not be a problem for the CA that you (after the domain has expired) still is in possession of a valid certificate for a domain which you do not have control over?

It sort of is. A CA shouldn't issue a certificate for a domain that may be released and repurchased before the cert expires.

> It's not the CA's job to make sure your domain isn't expiring. It's yours.

Really? In the simplest case, their entire job is certifying that the holder of the private key is the holder of the domain name[1]. That begs the question, of course: how is it that we trust every single CA to certify every single domain? Why don't we trust the issuer of each domain hierarchy to certify only those domains it's permitted to issue?

The entire XPKI is broken, broken, _broken_.

[1] In the more complex case, of course, they certify that the keyholder is some external entity.

Come on. It's the CA's job to accurately tell you who you're communicating with.

This was probably HSTS not a 301. HSTS headers include a validity, but 1yr is common. Good luck convince anyone to undo this, clearing cache does help and you need to dive into your browser internals for a fix: chrome://net-internals/#hsts

https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security

In such cases I always compare 'curl -I site' with the affected browser console.

Reply on news.ycombinator.com