nebula
nebula copied to clipboard
slackhq
Quick Start neglects to mention CA validity (default : 1 year)
Would suggest the Quick Start guide at https://www.defined.net/nebula/quick-start/ makes it clear that following the instructions creates a CA that is only valid for one year by default and perhaps encourages use of the -duration flag.
There's no mention of this in the documentation, so anyone following the Quick Start guide will find their installation starts to fail after one year in use.
This has also been raised in a comment on https://github.com/slackhq/nebula/issues/111 more than once before;
- https://github.com/slackhq/nebula/issues/111#issuecomment-1010017853
- https://github.com/slackhq/nebula/issues/111#issuecomment-1053243080
Following the quick start guide should not, by default, produce something that will fail after a year without warning.
That's a good idea. Would you like to submit a PR to https://github.com/DefinedNet/nebula-docs/blob/main/src/data/docs/en/quick-start.md to update the docs?
@IanVS I can do, I didn't realise the documentation was here! Will be next week though, so if anyone beats me to it that is also fine of course :)
Just to ensure understanding, do ALL three certs that are used expire in one year, i.e. ca.crt, (examples follow) lighthouse.crt and lighthouse.key. Seems they all would expire since the building and signing process needs the ca.crt and ca.key when building signing the others.
Is there a duration flag in the build and signing process that can bes et for a longer or shorter interval?
Thank-you!
Hi @johnjces, the CA cert expires in one year by default. Any other certs generated with nebula-cert sign by default expire 1 second before their signing CA cert expires. Both nebula-cert sign and nebula-cert ca accept a -duration flag to allow overriding these defaults.
Please forgive me as I am still learning and want to renew my certs before they expire. If I want to give my certificates a duration of five (5) years, do I need to set that in both sign and ca? Isn't the signing certificate the CA.CRT certificate and if so, if I set it for 5 years in hours, minutes or seconds, won't the client certificates (not the ca.crt) still expire one second before the CA.CRT?
Just trying to figure out if both need the same duration of just the main ca.crt, and if both do need the duration set, why?
Thanks so much!!
@johnjces host certs expire by default 1 second before the CA expires. So, if you create a new CA cert and configure it to expire in 5 years, then your host certs will, without a -duration flag specified, expire in 5 years also.
You can use the -duration flag when signing your host certs to make them expire in less time than the CA, but they can't outlive the CA that signs them.
Changing the default to 10y to avoid this completely unnecessary footgun is also advisable. I'd have just deployed a ticking time bomb if I'd not just stumbled across this issue.
Why update the documentation to tell someone their config's going to break when you could just, you know, not break it in the first place?
Hi @sneak - I'm sorry to hear this issue bit you. We recommend rotating your CAs on a regular cadence to reduce the validity period of an accidentally leaked private key.
The docs at https://nebula.defined.net/docs/guides/quick-start/#creating-keys-and-certificates have been updated with a note about the default 1-year validity period. As such, I'm closing this issue out.
That doesn't fix the problem. Change the default.
A documented footgun is still a footgun.
Hi @sneak - I'm sorry, we have no plans to change the default currently. We recommend that you rotate your CAs periodically to reduce the value of leaked CA private keys and the default validity period of 1 year reflects that.
Would displaying the CA's expiration date in the terminal during generation help you avoid being caught off-guard? Cheers!
If CA private keys are leaked, 1 year is too long. If they are not leaked, 1 year is too short.
A much better default would be 24 hours so your users get bitten by this while their configuration is still fresh in their minds, then they fix the problem (by setting a >=10y expiration) on day 2 instead of day 366.