9 ms·
Yeah. It's called Acmetool, LetsEncrypt, Cron, and Nagios. Problem solved. Free certs, automated, cronned, and externally monitored. What else do you need? Oh
by kefka 10y ago
Yeah. It's called Acmetool, LetsEncrypt, Cron, and Nagios.
Problem solved. Free certs, automated, cronned, and externally monitored. What else do you need?
Oh thats right. The feds forbid LE. Alright boys and girls, go back to your $499 Comodo certs.
- discreditable 10y agoExcept DHS's issues relate to certificates in a Windows environment, where Let's Encrypt does not have very good support. On top of that, I'd imagine their Active Directory domain controllers are not in the public DNS and they don't want them to be.
- dsp1234 10y agoin a Windows environment, Let's Encrypt does not have very good support. There are very good ACME clients (ACMESharp, etc) for windows that allow doing http-01 and dns-01 certificate issuance. Additionally, there is IIS integration (letsencrypt-win-simple) with the stuff you would expect (cert generation for all or specific sites, automatic renewal, etc). Basically the only thing Windows doesn't have is official support in the Certbot client.
- discreditable 10y agoLetsencrypt-win-simple only supports http-01. Acmesharp seems geared more towards developers (letsencrypt-win-simple uses it).
- hyperman1 10y agoMaybe you can clear up something for me: I am in CC for an email discussion between 2 parties exchanging sensitive personal information. Party A uses LetsEncrypt to protect the https site storing the information (And needs a username/password or something to grant access to Party B) Party B does certificate pinning, and complains that Party A's cert changes every three months without warning and without being sure the new cert still points to Party A. Party A says Party B should stop the pinning and just accept everything signed by LetsEncrypt. Party B says they want a way to be 100% sure they are talking with Party A and need a better (EV?) cert. The discussion is going back and forth for a few months now (and re-ignites every three months when communication goes down again and pissing everyone off). Who do you think is right here?
- jerf 10y ago1. Certificate pinning is not a solution to the problem. Certificates change without warning anyhow, because they may be compromised and revoked at any time. 2. Let's Encrypt certificates are indeed the lowest grade of SSL certificate. That's not a criticism of Let's Encrypt, it's just the nature of the situation. There are legitimate reasons to consider it too low a level of assurance. I have no idea whether your parties have that level of need or not. But I can point out that if you want a better grade of cert than Let's Encrypt, you do need to go for the fairly expensive ones that require a lot of real, human validation. There's not much point in just getting another cheap-but-not-free cert that has roughly the same level of validation. 3. There's another solution to this problem entirely, if you're communicating between two parties and that's all this cert is doing (i.e., you're not speaking to the general public with this cert). Make your own certificate authority, sign your own certs, have the public key of that CA inserted into the Java cert authority. Creating your own certificate authority is very simple. To give you a sense of how simple, here's some scripts I bashed together to set up nodes that speak to each other over SSL: Set up the CA [1] Build a new cert signed by that CA for the node [2]. I am NOT saying you can just use those or that you should even crib from them. These are generally intended for quick reference and testing only even in the context of this project ("real" users are expected to do their own cert management with real certs), and the needs of this project are significantly different from an HTTPS website. My intent in linking those is merely to demonstrate the rough complexity of setting up a CA is only a few lines in bash, not a monstrous impossibly-large undertaking, and you can Google this stuff up in a day or two, tops. The hard part is all around how careful you are with the private keys and revocation, and the fact you must set up and implement your own security policies around the certs. (My suggested revocation policy would be "we'll call you", and that if a cert is ever compromised, just re-roll the whole process from start to finish and create a new CA. "Real" revocation is somewhat complicated, and somewhat unsatisfactory anyhow. Take advantage of the smallness of the problem and the pre-existing personal connections. A lot of the at-scale SSL issues arise because we don't have those.) [1]: https://github.com/thejerf/reign/blob/master/create_signing_cert https://github.com/thejerf/reign/blob/master/create_signing_... [2]: https://github.com/thejerf/reign/blob/master/create_node_cert https://github.com/thejerf/reign/blob/master/create_node_cer...
- compuguy 10y agoLast I heard, for most federal agencies, a DV cert was all that was required?
- karlmdavis 10y ago> The feds forbid LE. Nope! Very much allowed -- at least for almost all applications. Here's just one example from a quick Google search that turned up lots of others: https://www.digitalgov.gov/2016/09/07/lets-encrypt-those-cnames-shall-we/ https://www.digitalgov.gov/2016/09/07/lets-encrypt-those-cna...
- jlgaddis 10y ago"The feds" run their own PKI and can easily generate all the certificates they want.