3 ms·

I'm working on this problem: https://sslmate.com/ https://sslmate.com/ Right now it's just a command line client, but a public API is in the works. And this w

by agwa 12y ago

I'm working on this problem: https://sslmate.com/ https://sslmate.com/ Right now it's just a command line client, but a public API is in the works. And this week we'll be announcing a solution to the cert rotation problem (basically, you'll be able to drive your renewals from cron - it's going to be really cool). You might want to follow @sslmate on Twitter - this is just the beginning of some very exciting stuff for automating SSL cert deployment. Also feel free to email me (address is in my profile). Sadly, we're still SHA-1 only, because that's all that our certificate authority (RapidSSL) supports at the moment. On the other hand, once we make renewals dead simple, you can just buy 1 year certs and it won't be a big deal upgrading to SHA-2 in a year's time. (After all, even Google is still using SHA-1, but they can easily switch thanks to their 3 month certs and well-oiled cert deployment machinery.)

zaroth 12y ago
Very interesting, thanks! I unpacked the .deb, the nodejs source is pretty easy to follow, so I'd say you pretty much already have the public API done. ;-) The /link API is interesting, versus generating a token on your site through the UI. You might want to consider allowing an explicit $$ limit on /buy, since you store the api-key in the clear (albeit in a config file set to 0600). It looks like you still rely on being able to receive an email on the domain and click an approval link, though. I'm sure this is a RapidSSL requirement, but it makes full automation more complex (certainly not impossible).
- agwa 12y ago
  Thanks for checking it out! Yeah, it's really just a matter of documenting the API ;-) Unfortunately it does rely on being able to receive an email, as this is a requirement of virtually all certificate authorities, though the email address in the whois record is also an option (at least for TLDs which list the email in whois). I have some ideas to make this easier for users who don't otherwise receive mail at their domains, such as by letting them point their MX record at sslmate. A configurable $ limit on /buy is a very good idea; also I should make it possible for users to use sslmate without permanently storing their API credentials on the filesystem.
aeden 12y ago
Are you certain RapidSSL is not accepting SHA-2 is not accepted by RapidSSL? Section 6.1.5.1 of http://www.rapidssl.com/resources/pdfs/geotrustCPSv1dot10.pdf http://www.rapidssl.com/resources/pdfs/geotrustCPSv1dot10.pd... seems to indicate that they do support SHA-2. Did you speak with them about this yet?

by agwa 12y ago

zaroth 12y ago

Very interesting, thanks! I unpacked the .deb, the nodejs source is pretty easy to follow, so I'd say you pretty much already have the public API done. ;-) The /link API is interesting, versus generating a token on your site through the UI. You might want to consider allowing an explicit $$ limit on /buy, since you store the api-key in the clear (albeit in a config file set to 0600). It looks like you still rely on being able to receive an email on the domain and click an approval link, though. I'm sure this is a RapidSSL requirement, but it makes full automation more complex (certainly not impossible).

agwa 12y ago
Thanks for checking it out! Yeah, it's really just a matter of documenting the API ;-) Unfortunately it does rely on being able to receive an email, as this is a requirement of virtually all certificate authorities, though the email address in the whois record is also an option (at least for TLDs which list the email in whois). I have some ideas to make this easier for users who don't otherwise receive mail at their domains, such as by letting them point their MX record at sslmate. A configurable $ limit on /buy is a very good idea; also I should make it possible for users to use sslmate without permanently storing their API credentials on the filesystem.

aeden 12y ago

Are you certain RapidSSL is not accepting SHA-2 is not accepted by RapidSSL? Section 6.1.5.1 of http://www.rapidssl.com/resources/pdfs/geotrustCPSv1dot10.pdf http://www.rapidssl.com/resources/pdfs/geotrustCPSv1dot10.pd... seems to indicate that they do support SHA-2. Did you speak with them about this yet?