Bug 1797593

Summary: revert bug 1797601 "force cert rotation every couple days for development" in 4.4
Product: OpenShift Container Platform Reporter: David Eads <deads>
Component: kube-apiserverAssignee: David Eads <deads>
Status: CLOSED ERRATA QA Contact: Ke Wang <kewang>
Severity: urgent Docs Contact:
Priority: urgent    
Version: 4.4CC: aos-bugs, mfojtik, nagrawal, sttts, xxia
Target Milestone: ---   
Target Release: 4.4.0   
Hardware: Unspecified   
OS: Unspecified   
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1806979 (view as bug list) Environment:
Last Closed: 2020-05-04 11:29:00 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On: 1806979    
Bug Blocks:    

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
if [ ! -f "$1" ]; then
  echo "must provide \$1" && exit 0
export IFS=$'\n'
for i in `cat "$FILE"`
  if `echo "$i" | grep "^#" > /dev/null`; then
  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

$ 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.