Description of problem:
After specifying a bad secret (one that doesn't contain tls.crt/tls.key) as a serving cert for the api server, modifying the secret or modifying the apiserver/cluster resource to point to a good secret does not fix the issue.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Create a serving cert secret with wrong keys (say crt,key instead of tls.crt,tls.key) in the openshift-config namespace.
2. Modify the apiserver/cluster resource and specify the new secret as the default serving cert:
3. Wait for kube-apiserver operator to apply the configuration and observe that one of the kube-apiserver pods starts crashlooping (as expected).
4. Modify the original secret to contain proper keys (tls.crt/tls.key). Wait for a change in the kube-apiserver pods.
5. Modify apiserver/cluster to point to a newly created secret that contains the right keys:
Wait for a change in the kube-apiserver pods.
After step 4 and/or 5, nothing changes. The one apiserver pod keeps crashlooping saying it can't find tls.crt.
After modifying the secret or the configuration, the secret should be updated on the master and the new serving cert should take effect.
Removing the serving certificate configuration completely:
and waiting for the kube-apiserver to become stable again does get around this issue.
Work-around is to specify the secret in the named certificates section:
In addition to the code fix, the docs were updated to remove the mention of using defaultServingCert, leaving the nameCertificates section (as shown in the 'work-around' above) as the appropriate way to accomplish what the originator was attempting to do. https://github.com/openshift/openshift-docs/pull/15642
(In reply to Luis Sanchez from comment #3)
> In addition to the code fix, the docs were updated to remove the mention of
> using defaultServingCert, leaving the nameCertificates section (as shown in
> the 'work-around' above) as the appropriate way to accomplish what the
> originator was attempting to do.
Right, for 4.2, bug 1731105#c3 verified defaultServingCert is removed, bug 1714771#c9 verified nameCertificates works. So moving this bug to VERIFIED.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.