<div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small;color:rgb(0,0,0)">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!<br> <br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small;color:rgb(0,0,0)">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.<br> <br></div><div class="gmail_extra"><div><div dir="ltr"><font><span style="font-family:verdana,sans-serif">Hartmut W Sager - Tel +1-204-339-8331<br></span></font><br></div></div>
<br><div class="gmail_quote">On 24 September 2014 00:24, Trevor Cordes <span dir="ltr"><<a href="mailto:trevor@tecnopolis.ca" target="_blank">trevor@tecnopolis.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">People who manage (paid for) SSL certs (for web servers, etc), don't<br>
make the same mistake I just did.<br>
<br>
It was renewal time and I did what I always do: blindly hit renew on my<br>
cert provider/reseller control panel. I get the cert, install into<br>
apache, restart, then boom:<br>
<br>
[ssl:emerg] [pid 11648] AH02565: Certificate and private key<br>
mydomain.blah:443:0 from /etc/pki/tls/certs/mycert.crt<br>
and /etc/pki/tls/private/mykey.key do not match AH00016:<br>
Configuration Failed<br>
<br>
After a very brief WTF moment, it dawned on me: "heartbleed". I<br>
regen'd my CSR/key and got a reissued cert a few months back. That is<br>
done direct with the vendor (Thawte), and *not* through my reseller<br>
(OpenSRS). So Thawte had my new CSR, but OpenSRS still had my old CSR<br>
on file (the one with the possibly-compromised heartbleed key) and that<br>
is the CSR they sent to Thawte when I renewed! Doh!<br>
<br>
So I had to make yet a new CSR/key, and have Thawte reissue a new cert,<br>
and then revoke the cert I (didn't) use for all of 5 seconds. Blah,<br>
there goes half an hour. I verified this is indeed what was happening<br>
with some openssl -modulus command line magic.<br>
<br>
I've written to notify OpenSRS they should put up a warning on the<br>
renewal page. This doubly sucks because OpenSRS *still* will have<br>
cached the revoked/compromised CSR and if I forget *next* year to paste<br>
a new CSR in, I'll be doing the exact same thing!<br>
<br>
Maybe the moral of the story is: always regen a new CSR everytime you<br>
renew. An extra 2 mins, and remembering some cryptic openssl commands,<br>
but not the end of the world, but still a pain vs. just hitting<br>
"renew". Maybe everyone else already does this and I wasn't following<br>
"best practices", but don't we all like to keep things simple when we<br>
can?<br>
<br>
Exercise for the curious/pedantic/strange people who read this far: Is<br>
there a way SRS or Thawte could have prevented this? Perhaps by<br>
linking the CSR used to make a revoked cert and disallowing renewals<br>
based on it? Or perhaps SRS needs an API with Thawte whereby you<br>
reissue via SRS, not Thawte, or Thawte needs to pass back the<br>
last-used-CSR to SRS so it can replace the stale cached copy.<br>
_______________________________________________<br>
Roundtable mailing list<br>
<a href="mailto:Roundtable@muug.mb.ca">Roundtable@muug.mb.ca</a><br>
<a href="http://www.muug.mb.ca/mailman/listinfo/roundtable" target="_blank">http://www.muug.mb.ca/mailman/listinfo/roundtable</a><br>
</blockquote></div><br></div></div>