3 ms·

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 u

by zephod 11y ago

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).

sparewalking 11y ago
In such cases I always compare 'curl -I site' with the affected browser console.
nly 11y ago
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.
- arbitrage 11y ago
  It's not the CA's job to make sure your domain isn't expiring. It's yours.
  - filleokus 11y ago
    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?
  - hueving 11y ago
    It sort of is. A CA shouldn't issue a certificate for a domain that may be released and repurchased before the cert expires.
  - wtbob 11y ago
    > 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.
  - draw_down 11y ago
    Come on. It's the CA's job to accurately tell you who you're communicating with.
notpeter 11y ago
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 https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security

by zephod 11y ago

sparewalking 11y ago

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

nly 11y ago

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.

arbitrage 11y ago
It's not the CA's job to make sure your domain isn't expiring. It's yours.
- filleokus 11y ago
  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?
- hueving 11y ago
  It sort of is. A CA shouldn't issue a certificate for a domain that may be released and repurchased before the cert expires.
- wtbob 11y ago
  > 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.
- draw_down 11y ago
  Come on. It's the CA's job to accurately tell you who you're communicating with.

notpeter 11y ago

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 https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security