3 ms·

They apparently have a “certificate wizard” that will generate the certificate and corresponding private key for you. Of course that’s practical for the end use

They apparently have a “certificate wizard” that will generate the certificate and corresponding private key for you. Of course that’s practical for the end user (generating a CSR can be cumbersome), but obviously insecure. They’re not the only party to do so either, e.g. DNSimple (which is otherwise a great company!) also provide APIs to have them generate and store certificates including private keys: https://developer.dnsimple.com/v2/certificates/#getCertificatePrivateKey https://developer.dnsimple.com/v2/certificates/#getCertifica...

bostik 9y ago
> They apparently have a [webgui] “certificate wizard” that will generate the certificate and corresponding private key for you. Any company doing that deserves to have their decision makers crucified, head down, on the outer wall of the town church, with the nails hammered through their genitals. If you didn't create the private key yourself, by definition it's not private. If generating CRSs and handling the certificates is too difficult, then feed improvements upstream. And yes, I know how horrible openssl's UI is for dealing with anything other than CN based certs. It's awful enough for those, an absolutely atrocious for pretty much anything else. For the record, CN has been deprecated in certificates since ~2000 (RFC 2818), and practically obsoleted since 2011 (RFC 6125). Regardless of all this, I have dealt (in 2017) with parties who don't understand SAN over CN, and have even had their software stacks blow up when I provide a cert with SANs only, and no CN.
- ceejayoz 9y ago
  > If you didn't create the private key yourself, by definition it's not private. In fairness, though, your certificate vendor already has the power to issue a brand new certificate for your domain if they wanted to quietly snoop on traffic. Same thing with AWS generating SSH keys if you want them to - they can get at all the data on your server anyways. No, it's not the greatest practice, but it probably does help a bit for making things easier for less-technical users.
  - tialaramex 9y ago
    Misconceptions at work: If a hypothetical Bad Guy has got a different Certificate for my site they cannot "quietly snoop on traffic". They have to do an active Man-in-the-middle attack on each connection or else it's completely opaque to them. Each of the clients they do this to receives a free Smoking Gun, a copy of their illegitimate certificate showing who signed it and when. In a future where CT policy enforcement is completed (not yet but maybe soon) they must also have logged the certificate so that everybody can see it, or it won't work. If the hypothetical Bad Guy has my Private Key, they can quietly snoop traffic using ciphersuites which lack "Forward Secrecy" although no popular browser will choose this unless forced to, and in TLS 1.3 Forward Secrecy is mandatory. If the Bad Guy has my Private Key and is willing to do a Man-in-the-middle attack the same applies as above, except that I don't learn anything from Certificate Transparency since they can use my cert as they know the key for it.
- zokier 9y ago
  That's bit harsh. I bet that significant amount of the impacted people had only the vaguest idea what they were actually buying ("a lock icon for the web thingy"), and never even heard of private keys, never mind CSRs or actually understanding public-key crypto and PKI.
  - icebraining 9y ago
    I find this argument unconvincing, but even if you really feel the need to help people generate keys, you do it in JS in the browser, without ever sending them to your server! Open source code to do this has been around since 2001: http://webcache.googleusercontent.com/search?q=cache:87MSSBjLHGkJ:shop-js.sourceforge.net/crypto2.htm+&cd=2&hl=en&ct=clnk&gl=lu&client=ubuntu http://webcache.googleusercontent.com/search?q=cache:87MSSBj...
- jackfraser 9y ago
  > Any company doing that deserves to have their decision makers crucified, head down, on the outer wall of the town church, with the nails hammered through their genitals. You're the security hero we need, but not the one we deserve
jackfraser 9y ago
Ah, didn't know that. While it lowers the barrier to entry for getting a cert, the idea is fundamentally insecure.

bostik 9y ago

> They apparently have a [webgui] “certificate wizard” that will generate the certificate and corresponding private key for you. Any company doing that deserves to have their decision makers crucified, head down, on the outer wall of the town church, with the nails hammered through their genitals. If you didn't create the private key yourself, by definition it's not private. If generating CRSs and handling the certificates is too difficult, then feed improvements upstream. And yes, I know how horrible openssl's UI is for dealing with anything other than CN based certs. It's awful enough for those, an absolutely atrocious for pretty much anything else. For the record, CN has been deprecated in certificates since ~2000 (RFC 2818), and practically obsoleted since 2011 (RFC 6125). Regardless of all this, I have dealt (in 2017) with parties who don't understand SAN over CN, and have even had their software stacks blow up when I provide a cert with SANs only, and no CN.

ceejayoz 9y ago
> If you didn't create the private key yourself, by definition it's not private. In fairness, though, your certificate vendor already has the power to issue a brand new certificate for your domain if they wanted to quietly snoop on traffic. Same thing with AWS generating SSH keys if you want them to - they can get at all the data on your server anyways. No, it's not the greatest practice, but it probably does help a bit for making things easier for less-technical users.
- tialaramex 9y ago
  Misconceptions at work: If a hypothetical Bad Guy has got a different Certificate for my site they cannot "quietly snoop on traffic". They have to do an active Man-in-the-middle attack on each connection or else it's completely opaque to them. Each of the clients they do this to receives a free Smoking Gun, a copy of their illegitimate certificate showing who signed it and when. In a future where CT policy enforcement is completed (not yet but maybe soon) they must also have logged the certificate so that everybody can see it, or it won't work. If the hypothetical Bad Guy has my Private Key, they can quietly snoop traffic using ciphersuites which lack "Forward Secrecy" although no popular browser will choose this unless forced to, and in TLS 1.3 Forward Secrecy is mandatory. If the Bad Guy has my Private Key and is willing to do a Man-in-the-middle attack the same applies as above, except that I don't learn anything from Certificate Transparency since they can use my cert as they know the key for it.
zokier 9y ago
That's bit harsh. I bet that significant amount of the impacted people had only the vaguest idea what they were actually buying ("a lock icon for the web thingy"), and never even heard of private keys, never mind CSRs or actually understanding public-key crypto and PKI.
- icebraining 9y ago
  I find this argument unconvincing, but even if you really feel the need to help people generate keys, you do it in JS in the browser, without ever sending them to your server! Open source code to do this has been around since 2001: http://webcache.googleusercontent.com/search?q=cache:87MSSBjLHGkJ:shop-js.sourceforge.net/crypto2.htm+&cd=2&hl=en&ct=clnk&gl=lu&client=ubuntu http://webcache.googleusercontent.com/search?q=cache:87MSSBj...
jackfraser 9y ago
> Any company doing that deserves to have their decision makers crucified, head down, on the outer wall of the town church, with the nails hammered through their genitals. You're the security hero we need, but not the one we deserve

jackfraser 9y ago

Ah, didn't know that. While it lowers the barrier to entry for getting a cert, the idea is fundamentally insecure.