Bugzilla – Bug 1136246
Invalid certificate with Admin node. build 20190521
Last modified: 2019-06-05 08:21:24 UTC
Issue: Unable to initialize certificates or kubicctl admin:~ # kubicctl certificates initialize Error invoking certstrap: exit status 1 CA with specified name "Kubic-Control-CA" already exists! Error creating CA: exit status 1 admin:~ # kubicctl init --pod-network cilium Initializing kubernetes master can take several minutes, please be patient. Could not initialize: rpc error: code = Unavailable desc = all SubConns are in TransientFailure, latest connection error: connection error: desc = "transport: authentication handshake failed: x509: certificate has expired or is not yet valid"
I also confirmed that the date is correct: admin:~ # date Fri 24 May 2019 02:59:42 PM UTC This is the same as my local machine: jsevans@work:~> date Fri May 24 17:00:23 CEST 2019
systemctl is-enabled kubicd-init Is that enabled? If you look at the timestamp of the certificates in /etc/kubicd/pki, looks the time of the files correct? What is the validy timeframe if you run: openssl x509 -in /etc/kubicd/pki/Kubic-Control-CA.crt -text -noout I could only imagine, that either the systemd service to create the certificates did run before the time was set correct, ~/.config/kubicctl/user.* does not match /etc/kubicd/pki/admin.*, or something broke the files in /etc/kubicd/pki
(In reply to Thorsten Kukuk from comment #2) > systemctl is-enabled kubicd-init > > Is that enabled? It is enabled but it failed. linux-623w:~ # systemctl status kubicd-init ● kubicd-init.service - Create certificates for KubicD Loaded: loaded (/usr/lib/systemd/system/kubicd-init.service; enabled; vendor preset: disabled) Active: inactive (dead) Condition: start condition failed at Sat 2019-06-01 10:41:20 UTC; 1h 14min ago Jun 01 10:41:20 linux-623w systemd[1]: Condition check resulted in Create certificates for KubicD being skipped. > > If you look at the timestamp of the certificates in /etc/kubicd/pki, looks > the time of the files correct? > > What is the validy timeframe if you run: > openssl x509 -in /etc/kubicd/pki/Kubic-Control-CA.crt -text -noout > > linux-623w:~ # openssl x509 -in /etc/kubicd/pki/Kubic-Control-CA.crt -text -noout Certificate: Data: Version: 3 (0x2) Serial Number: 1 (0x1) Signature Algorithm: sha256WithRSAEncryption Issuer: CN = Kubic-Control-CA Validity Not Before: Jun 1 10:31:42 2019 GMT Not After : Dec 1 10:31:42 2020 GMT Subject: CN = Kubic-Control-CA Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public-Key: (4096 bit) Modulus: xxx Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Key Usage: critical Certificate Sign, CRL Sign X509v3 Basic Constraints: critical CA:TRUE, pathlen:0 X509v3 Subject Key Identifier: 1D:8C:D3:5C:B2:5C:11:9B:79:75:99:A9:BB:BA:59:5D:29:C6:FF:0A Signature Algorithm: sha256WithRSAEncryption xxx > I could only imagine, that either the systemd service to create the > certificates did run before the time was set correct, > ~/.config/kubicctl/user.* does not match /etc/kubicd/pki/admin.*, or > something broke the files in /etc/kubicd/pki
(In reply to Jason Evans from comment #3) > linux-623w:~ # openssl x509 -in /etc/kubicd/pki/Kubic-Control-CA.crt -text > -noout > Certificate: > Data: > Version: 3 (0x2) > Serial Number: 1 (0x1) > Signature Algorithm: sha256WithRSAEncryption > Issuer: CN = Kubic-Control-CA > Validity > Not Before: Jun 1 10:31:42 2019 GMT > Not After : Dec 1 10:31:42 2020 GMT This looks like a new installation and not from the system where the error did occur? Do you even with the new certificate still see the error?
This is an autogenerated message for OBS integration: This bug (1136246) was mentioned in https://build.opensuse.org/request/show/707186 Factory / kubic-control
Under the assumption, that the time was not set when the certificates where created, and you didn't mix up certificates generated at different times/on different machines, then this is partly fixed. We wait now that the time is set before we create the certificates. During this we found other bugs in setting up chrony, YaST team is currently fixing them: [bsc#1137196] - chrony-wait.service not enabled