Bug 1797593 - revert bug 1797601 "force cert rotation every couple days for development" in 4.4
Summary: revert bug 1797601 "force cert rotation every couple days for development" in...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: kube-apiserver
Version: 4.4
Hardware: Unspecified
OS: Unspecified
urgent
urgent
Target Milestone: ---
: 4.4.0
Assignee: David Eads
QA Contact: Ke Wang
URL:
Whiteboard:
: 1803704 (view as bug list)
Depends On: 1806979
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-02-03 13:33 UTC by David Eads
Modified: 2020-05-04 11:29 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1806979 (view as bug list)
Environment:
Last Closed: 2020-05-04 11:29:00 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Github openshift cluster-kube-apiserver-operator pull 771 None closed Bug 1797593: Revert "force cert rotation every couple days for development" 2020-10-06 13:41:00 UTC

Description David Eads 2020-02-03 13:33:00 UTC
We want short expiry times during development and long expiry times when we ship.

Comment 1 Stefan Schimanski 2020-02-24 12:25:17 UTC
*** Bug 1803704 has been marked as a duplicate of this bug. ***

Comment 4 Ke Wang 2020-02-28 03:22:15 UTC
Using below steps to verify this bug:
$ cat scripts/check_secret_expiry.sh
FILE="$1"
if [ ! -f "$1" ]; then
  echo "must provide \$1" && exit 0
fi
export IFS=$'\n'
for i in `cat "$FILE"`
do
  if `echo "$i" | grep "^#" > /dev/null`; then
    continue
  fi
  NS=`echo $i | cut -d ' ' -f 1`
  SECRET=`echo $i | cut -d ' ' -f 2`
  rm -f tls.crt; oc extract secret/$SECRET -n $NS --confirm > /dev/null
  echo "Check cert dates of $SECRET in project $NS:"
  openssl x509 -noout --dates -in tls.crt; echo
done

$ cat certs.txt
openshift-kube-controller-manager-operator csr-signer-signer
openshift-kube-controller-manager-operator csr-signer
openshift-kube-controller-manager kube-controller-manager-client-cert-key
openshift-kube-apiserver-operator aggregator-client-signer
openshift-kube-apiserver aggregator-client
openshift-kube-apiserver external-loadbalancer-serving-certkey
openshift-kube-apiserver internal-loadbalancer-serving-certkey
openshift-kube-apiserver service-network-serving-certkey
openshift-config-managed kube-controller-manager-client-cert-key
openshift-config-managed kube-scheduler-client-cert-key
openshift-kube-scheduler kube-scheduler-client-cert-key

Checking the Certs,  they are with one day expiry times, this is as expected.

$ bash ./check-secret-expiry.sh cert.txt
Check cert dates of csr-signer-signer in project openshift-kube-controller-manager-operator:
notBefore=Feb 27 02:54:14 2020 GMT
notAfter=Feb 28 02:54:14 2020 GMT
...

After one day, checking the cert rotation again, 

$ ./check-secret-expiry.sh ./cert.txt 
Check cert dates of csr-signer-signer in project openshift-kube-controller-manager-operator:
notBefore=Feb 27 22:06:13 2020 GMT
notAfter=Apr 27 22:06:14 2020 GMT

Check cert dates of csr-signer in project openshift-kube-controller-manager-operator:
notBefore=Feb 27 22:09:43 2020 GMT
notAfter=Mar 28 22:09:44 2020 GMT
...

All certs are as expected expiry time 30 days, except cert of of csr-signer-signer in project openshift-kube-controller-manager-operator with 2 * 30 days, see above , is this as expected?

@deads2k : Any comments?
CC @xxia

Comment 7 errata-xmlrpc 2020-05-04 11:29:00 UTC
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.

https://access.redhat.com/errata/RHBA-2020:0581


Note You need to log in before you can comment on or make changes to this bug.