Am 13.09.2017 um 14:36 schrieb Hector Martin <firstname.lastname@example.org>:
I have a similar use case. I'm building an internal PKI but intend to issue short-lived certs (like Let's Encrypt); the idea is that by automating cert renewal and doing it often you can make sure the actual renewal process works and is tested, and it reduces the window of vulnerability if a cert is compromised. In the long run that also cuts down on the risk of "the certs expired and the cluster died all of a sudden since nobody noticed" scenarios.
The problem is that if cert renewals require a full restart, then that needs to be coordinated between nodes. If reloads can be done with no downtime, that means servers can be responsible for requesting renewal of their own cert on their own schedule. If downtime is involved then at minimum I'd have to use a fixed cron schedule to make sure nodes never restart at the same time, which is less ideal.
Why do you think cert reloads would open an attack vector? Surely if an attacker can change the certs on disk they can also restart Elasticsearch, assuming no egregious filesystem permissions issues.
On Tuesday, August 22, 2017 at 10:31:44 AM UTC+9, Tom Ryan wrote:
Let's Encrypt certs expire after 90 days, and are typically renewed after 60. The key, as you might expect, doesn't change.
I mostly asked because I saw Let's Encrypt mentioned in the latest example configs. After I thought about it a bit more, I decided it wasn't for me because of the immense trust it places in public DNS (which mostly cannot be avoided, but since we control all the clients, in this case it can).
But to answer your questions: reload could avoid having to rolling restart every ~60 days, and I'd expect it to either watch the files on disk or be called after successful renewal by the `certbot` renewal client.
On Saturday, 19 August 2017 06:44:16 UTC+10, Jochen Kressin wrote:
Just out of curiosity - what is your use case for auto-reloading the certificates? I understand that the Let's Encrypt certificates have an expiration date and you would need to renew them from time to time. Which would also mean a rolling restart of the cluster. However, automatically reloading the certificates would open a potential attack vector, which is why we decided against it, and rather support certificate revocation lists. How would you use an automatic certificate reload feature?
On Thursday, August 17, 2017 at 2:04:35 AM UTC+2, Tom Ryan wrote:
In that case, I'll stick with using our internal PKI. I trust it a bit more than Let's Encrypt anyway tbh. I do think it would be great ti have a way to reread/reload either the cert or searchguard-ssl itself, without doing a full node restart.
On Thursday, 17 August 2017 07:00:51 UTC+10, Jochen Kressin wrote:
Yes, any changes to the certificates require a restart of your node(s) in order for Search Guard to pick up the new certificates. The certs are loaded on start up of the node(s).
On Wednesday, August 16, 2017 at 7:50:19 AM UTC+2, Tom Ryan wrote:
When asking questions, please provide the following information:
* Search Guard and Elasticsearch version
* Used enterprise modules, if any
* JVM version and operating system version
* Search Guard configuration files
* Elasticsearch log messages on debug level
I'm working on upgrading our 2.x cluster to 5.5.1, and searchguard-ssl therefore to 5.5.1-23, and I see that PEM certs are now usable in recent versions of searchguard-ssl (with a mention of letsencrypt in the example config).
Will cert renewals require a restart of each Elasticsearch instance? Or will the file changing on disk cause searchguard-ssl to re-read?
If there are any other good practices and/or gotchas to think about here, I'd love to hear them.
Thanks in advance,
You received this message because you are subscribed to the Google Groups "Search Guard Community Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to email@example.com.
To post to this group, send email to firstname.lastname@example.org.
To view this discussion on the web visit https://groups.google.com/d/msgid/search-guard/d692488a-434b-4ab0-a2b9-193ed7ebfc6c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.