Just ran into a case where credhub had an old TLS CA certificate for a test deployment I use everywhere, and that CA had expired. This lead to some obscure breakage in the API server, which was unable to talk to etcd (because it couldn't / wouldn't validate with an expired CA in the chain).
Unfortunately, this manifested as a low-level gnutls error:
gnutls_handshake() failed: Certificate is bad
While true, this error is pretty ambiguous - is the etcd server cert bad? The api's client cert? Turns out it was the CA.
I eventually got past the issue by deleting the (generated) CA certificate so that a subsequent bosh deploy would re-create it (and I'd be good for another year!), but I would really like to see some validation in pre-start (or, if possible, in the job rendering templates via a raise) that checks:
The CA certificate must have the CA:TRUE constraint
Just ran into a case where credhub had an old TLS CA certificate for a test deployment I use everywhere, and that CA had expired. This lead to some obscure breakage in the API server, which was unable to talk to etcd (because it couldn't / wouldn't validate with an expired CA in the chain).
Unfortunately, this manifested as a low-level gnutls error:
While true, this error is pretty ambiguous - is the etcd server cert bad? The api's client cert? Turns out it was the CA.
I eventually got past the issue by deleting the (generated) CA certificate so that a subsequent
bosh deploywould re-create it (and I'd be good for another year!), but I would really like to see some validation in pre-start (or, if possible, in the job rendering templates via a raise) that checks:CA:TRUEconstraint