Regenerate self-provisioned ES TLS cert when it's outdated #1301
Conversation
…is invalid Signed-off-by: Kevin Earls <kearls@redhat.com>
Codecov Report
@@ Coverage Diff @@
## master #1301 +/- ##
=======================================
Coverage 87.37% 87.37%
=======================================
Files 89 89
Lines 4976 4976
=======================================
Hits 4348 4348
Misses 465 465
Partials 163 163 Continue to review full report at Codecov.
|
jpkrohling
changed the title
| @@ -207,6 +207,12 @@ function generate_certs() { | |||
| local component=$1 | |||
| local extensions=${2:-} | |||
|
|
|||
| # For TRACING-1631 - if we can't find the namespace in the cert it's bad, regenerate everything | |||
| if [ $REGENERATE_NEEDED = 0 ] && [ "${component}" == "elasticsearch" ] && [ -f ${WORKING_DIR}/logging-es.crt ] ; then | |||
| openssl x509 -in ${WORKING_DIR}/logging-es.crt -text | grep -q "DNS:elasticsearch.${NAMESPACE}.svc" | |||
There was a problem hiding this comment.
We can merge without this change, but isn't there a command to extract only this field from the cert?
There was a problem hiding this comment.
This can be merged right away if we need to, but wanted to clarify whether we can extract the SAN explicitly from the cert instead of getting the cert's text and using grep to find something that looks like a SAN field. This improvement can be done later, though.
|
@jpkrohling Agreed on the SAN. The problem here is that I could not explicitly extract the SAN with the version of OpenSSL I had on my Mac, even after update, as it did not have the -ext option. |
Force cert regeneration for self prov elasticsearch instances if SAN is invalid
Signed-off-by: Kevin Earls kearls@redhat.com