People who manage (paid for) SSL certs (for web servers, etc), don't make the same mistake I just did.
It was renewal time and I did what I always do: blindly hit renew on my cert provider/reseller control panel. I get the cert, install into apache, restart, then boom:
[ssl:emerg] [pid 11648] AH02565: Certificate and private key mydomain.blah:443:0 from /etc/pki/tls/certs/mycert.crt and /etc/pki/tls/private/mykey.key do not match AH00016: Configuration Failed
After a very brief WTF moment, it dawned on me: "heartbleed". I regen'd my CSR/key and got a reissued cert a few months back. That is done direct with the vendor (Thawte), and *not* through my reseller (OpenSRS). So Thawte had my new CSR, but OpenSRS still had my old CSR on file (the one with the possibly-compromised heartbleed key) and that is the CSR they sent to Thawte when I renewed! Doh!
So I had to make yet a new CSR/key, and have Thawte reissue a new cert, and then revoke the cert I (didn't) use for all of 5 seconds. Blah, there goes half an hour. I verified this is indeed what was happening with some openssl -modulus command line magic.
I've written to notify OpenSRS they should put up a warning on the renewal page. This doubly sucks because OpenSRS *still* will have cached the revoked/compromised CSR and if I forget *next* year to paste a new CSR in, I'll be doing the exact same thing!
Maybe the moral of the story is: always regen a new CSR everytime you renew. An extra 2 mins, and remembering some cryptic openssl commands, but not the end of the world, but still a pain vs. just hitting "renew". Maybe everyone else already does this and I wasn't following "best practices", but don't we all like to keep things simple when we can?
Exercise for the curious/pedantic/strange people who read this far: Is there a way SRS or Thawte could have prevented this? Perhaps by linking the CSR used to make a revoked cert and disallowing renewals based on it? Or perhaps SRS needs an API with Thawte whereby you reissue via SRS, not Thawte, or Thawte needs to pass back the last-used-CSR to SRS so it can replace the stale cached copy.
I have not ever done SSL with Tucows/OpenSRS (though I was planning to do so), but I've sure had quite a lot of experience with Tucows/OpenSRS on domain registrations and management. From this, I can say: They are a wonderful and pleasant, totally Canadian, company to deal with, but they are very badly screwed up at their entire reseller interface end. Numerous complaints of mine (in direct phone discussion with appropriate tech people there) have resulted in acknowledgement of the problems, but no fixes ever!
Since the reseller interface end is software of theirs, it is reasonable to suspect that other software at their end, like their SSL cert matters, might also be screwed up.
Hartmut W Sager - Tel +1-204-339-8331
On 24 September 2014 00:24, Trevor Cordes trevor@tecnopolis.ca wrote:
People who manage (paid for) SSL certs (for web servers, etc), don't make the same mistake I just did.
It was renewal time and I did what I always do: blindly hit renew on my cert provider/reseller control panel. I get the cert, install into apache, restart, then boom:
[ssl:emerg] [pid 11648] AH02565: Certificate and private key mydomain.blah:443:0 from /etc/pki/tls/certs/mycert.crt and /etc/pki/tls/private/mykey.key do not match AH00016: Configuration Failed
After a very brief WTF moment, it dawned on me: "heartbleed". I regen'd my CSR/key and got a reissued cert a few months back. That is done direct with the vendor (Thawte), and *not* through my reseller (OpenSRS). So Thawte had my new CSR, but OpenSRS still had my old CSR on file (the one with the possibly-compromised heartbleed key) and that is the CSR they sent to Thawte when I renewed! Doh!
So I had to make yet a new CSR/key, and have Thawte reissue a new cert, and then revoke the cert I (didn't) use for all of 5 seconds. Blah, there goes half an hour. I verified this is indeed what was happening with some openssl -modulus command line magic.
I've written to notify OpenSRS they should put up a warning on the renewal page. This doubly sucks because OpenSRS *still* will have cached the revoked/compromised CSR and if I forget *next* year to paste a new CSR in, I'll be doing the exact same thing!
Maybe the moral of the story is: always regen a new CSR everytime you renew. An extra 2 mins, and remembering some cryptic openssl commands, but not the end of the world, but still a pain vs. just hitting "renew". Maybe everyone else already does this and I wasn't following "best practices", but don't we all like to keep things simple when we can?
Exercise for the curious/pedantic/strange people who read this far: Is there a way SRS or Thawte could have prevented this? Perhaps by linking the CSR used to make a revoked cert and disallowing renewals based on it? Or perhaps SRS needs an API with Thawte whereby you reissue via SRS, not Thawte, or Thawte needs to pass back the last-used-CSR to SRS so it can replace the stale cached copy. _______________________________________________ Roundtable mailing list Roundtable@muug.mb.ca http://www.muug.mb.ca/mailman/listinfo/roundtable
Since the reseller interface end is software of theirs, it is reasonable to suspect that other software at their end, like their SSL cert matters, might also be screwed up.
I'll admit OpenSRS's interfaces are a bit "quirky", but the one thing I like about them is that at least they are consistent: their reseller interface (mostly) and the end-user management pages haven't changed in a decade. If there's one thing I hate, it's change for change's sake (ehem, Microsoft, Apple, ehem).
So at least you know where it's wonky, and how to work around it, because it never improves nor gets worse. :-)
(Hey, let's at least give them credit for having a timely heartbleed warning up on the pages!)
P.S. If you're ever looking for an OpenSRS reseller who can finagle special deals and tweaks for an enterprising businessman, let me know. Assuming you aren't a OpenSRS direct reseller yourself, of course :-)
I had meant to say a few weeks ago already, when Trevor gave extensive quality answers on some topic and mentioned that he is an OpenSRS reseller: Please bring Trevor any related business you possibly can, since he truly merits it. Sure, I'm an OpenSRS reseller too, but Trevor is the one who deserves the business.
As for OpenSRS's "stable wonkiness", yes, good point. I too really hate change for change's sake. However, some things in their domain registration and management area aren't just quirky - they're outrightly buggy or defective, preventing proper use.
Hartmut W Sager - Tel +1-204-339-8331
On 24 September 2014 00:53, Trevor Cordes trevor@tecnopolis.ca wrote:
Since the reseller interface end is software of theirs, it is reasonable to suspect that other software at their end, like their SSL cert matters, might also be screwed up.
I'll admit OpenSRS's interfaces are a bit "quirky", but the one thing I like about them is that at least they are consistent: their reseller interface (mostly) and the end-user management pages haven't changed in a decade. If there's one thing I hate, it's change for change's sake (ehem, Microsoft, Apple, ehem).
So at least you know where it's wonky, and how to work around it, because it never improves nor gets worse. :-)
(Hey, let's at least give them credit for having a timely heartbleed warning up on the pages!)
P.S. If you're ever looking for an OpenSRS reseller who can finagle special deals and tweaks for an enterprising businessman, let me know. Assuming you aren't a OpenSRS direct reseller yourself, of course :-) _______________________________________________ Roundtable mailing list Roundtable@muug.mb.ca http://www.muug.mb.ca/mailman/listinfo/roundtable
-
Hartmut W Sager -
Trevor Cordes