Description of problem: The service-ca.crt has a duplicate certificate Issuer: CN=openshift-service-serving-signer@1574179295 with different signature algorithm: Certificate: Data: Version: 3 (0x2) Serial Number: 1 (0x1) Signature Algorithm: sha256WithRSAEncryption Issuer: CN=openshift-service-serving-signer@1574179295 X509v3 extensions: X509v3 Key Usage: critical Digital Signature, Key Encipherment, Certificate Sign X509v3 Basic Constraints: critical CA:TRUE X509v3 Subject Key Identifier: 40:1F:AB:28:EA:8A:54:73:82:33:80:07:D4:88:DB:9E:CD:39:5F:77 X509v3 Authority Key Identifier: keyid:40:1F:AB:28:EA:8A:54:73:82:33:80:07:D4:88:DB:9E:CD:39:5F:77 Signature Algorithm: sha256WithRSAEncryption 51:b0:da:e7:e4:4b:6b:2b:d0:22:e0:8c:d8:02:e1:39:08:da: 03:fe:c1:55:75:0d:d0:e0:0c:ed:1d:57:fd:63:70:b8:db:56: 01:2a:84:17:c6:40:3f:1b:51:99:3f:53:fe:df:7a:76:67:17: c6:ad:54:91:c8:d9:38:bc:c3:e4:ce:c4:04:eb:38:fe:9e:c5: d5:05:a0:2f:51:74:29:07:f0:e8:ca:70:61:32:d9:2a:5c:c6: ff:f5:8a:71:c5:af:3e:0a:67:ec:7f:18:42:10:9a:0e:82:65: 5e:c8:9a:d0:36:16:2d:95:a7:be:a4:ad:ab:82:07:7f:f2:5a: 02:12:dc:7d:a0:70:57:8e:92:ed:33:7c:eb:ff:28:f5:e9:19: 2d:c5:3b:8a:18:13:3c:84:6c:f9:e2:2a:2c:55:e7:23:fe:83: e2:a9:24:f3:94:41:1b:27:47:f8:92:14:21:b0:a7:10:ad:6d: 46:d1:59:e4:bd:bf:7c:dc:99:a5:2c:ca:65:f0:0c:95:e6:18: 1d:ae:19:04:97:46:3d:53:3c:ee:55:50:5c:5d:fa:8a:9f:12: 71:d5:7d:f1:97:70:c4:cb:79:97:f6:45:b7:66:d4:ae:28:bc: 72:e0:e1:f1:ff:28:1c:0e:39:95:d3:e9:28:aa:09:79:85:1f: 7b:89:40:05 Certificate: Data: Version: 3 (0x2) Serial Number: 1 (0x1) Signature Algorithm: sha256WithRSAEncryption Issuer: CN=openshift-service-serving-signer@1574179295 Validity Not Before: Nov 19 16:01:34 2019 GMT Not After : Apr 11 11:30:50 2021 GMT Subject: CN=openshift-service-serving-signer@1574179295 Subject Public Key Info: Public Key Algorithm: rsaEncryption Signature Algorithm: sha256WithRSAEncryption 9f:fd:7f:69:49:7c:25:44:1e:48:86:e4:84:a3:56:23:e8:ec: 26:0b:58:55:79:89:3e:bf:52:40:d4:c8:58:5f:12:43:99:64: 42:c4:22:1c:1e:02:2e:d2:5e:11:8d:50:c9:df:aa:94:49:ad: a0:0a:50:fb:d4:81:58:45:60:30:88:16:fb:f8:b1:9c:e4:d8: 6f:43:2e:07:23:8f:d9:49:04:5c:c9:50:87:6d:2a:37:05:e9: 1f:85:87:2e:35:30:fa:3c:b5:66:88:f8:0e:a0:a1:10:3b:37: a6:6e:32:f9:11:f9:64:e7:a7:2b:0d:6a:fd:b1:17:41:4f:9c: e1:29:e0:85:c8:6a:58:2a:cd:44:1b:75:80:c2:3d:e3:86:15: c9:8b:24:c7:2f:23:61:09:0b:b6:28:2d:be:b3:b6:7e:93:65: f4:e2:45:0f:86:e1:e0:4c:0f:70:be:77:a5:45:67:6d:f6:ab: da:c5:12:b0:63:a6:b3:a5:29:0c:59:32:d1:5b:b5:4f:54:03: ff:64:e9:e1:a9:f2:4f:c8:b2:d8:5a:bd:91:08:fe:b7:6d:87: 6a:f8:8b:4f:9a:5c:3e:af:c3:1c:03:7c:c1:88:8b:9a:35:f0: 81:7b:87:86:86:5c:2d:24:7a:0a:57:13:fa:9f:8f:ec:c1:cd: 11:36:cd:05 The question that arise : Why a duplicated entry for the service signing CA is projected into /var/run/secrets/kubernetes.io/serviceaccount/service-ca.crt? How to handle such situation ? Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
From https://bugzilla.redhat.com/show_bug.cgi?id=1913217#c1: The underlying problem (service ca certs not being generated with unique serials) has been fixed in releases shipped since ~April 2020 as per [1]. A customer experiencing a problem with non-unique serials in service ca certs is likely to have updated to a version that included the serial number bug in the service ca rotation implementation (e.g. 4.3.5) before those releases were pulled as per [2]. Resolution for a cluster whose release version includes the serial number fix (definitely true for 4.6.x) involves a one-time manual rotation of the service ca as per the following instructions: https://docs.openshift.com/container-platform/4.6/security/certificates/service-serving-certificate.html#manually-rotate-service-ca_service-serving-certificate After following these instructions, the serving ca certs will be guaranteed to have unique serial numbers, and subsequent automatic CA rotations will also ensure this. As to the question of 3 certs being included in a serving cert secret, this is intentional. The certs are as follows: - serving certificate - intermediate certificate bridging trust between the service certificate and the previous CA - the current CA The first 2 are required. The last one is an accident of implementation we are maintaining indefinitely to avoid breaking customers that reused the serving cert as a ca bundle as per [3]. 1: https://bugzilla.redhat.com/show_bug.cgi?id=1810036 2: https://bugzilla.redhat.com/show_bug.cgi?id=1814390 3: https://bugzilla.redhat.com/show_bug.cgi?id=1772067 *** This bug has been marked as a duplicate of bug 1913217 ***