I ran into issue with expired certificates on k8s cluster. I am running version 1.6.1 for over a year now, meaning that my certificates expired and I have to renew them.
In newer versions this is already done automatically, but I currently can not upgrade my cluster to higher version, so I have to create certificates manually.
I came across following link, where it is described step-by-step, but I am actually already stuck on creating openssl.cnf file, as I am missing parameters. At the same time, this option is using .pem key, while on cluster currently .crt and .key pairs are used.
Any suggestion how to move forward with this? I have also tried running kubeadm alpha phase certs selfsign command, which created new certificates, yet I am still running into issue that api-server is refusing TSL handshake.
http: TLS handshake error from IP:port: remote error: tls: bad certificate
Thank you and best regards,
Bostjan
There is a detailed guide on how to generate certificates.
While you are following that guide look out for a few gotchas:
Make sure your CA certificate is valid for the period you are trying to extend the other certificates to. The validity of any certificates signed by the CA certificate are also limited by the expiration date of the CA certificate.
If the validity period of the CA certificate itself is too short you are in a pickle. Replacing that certificate will require modifying all kubeconfigs (operators, cluster components).
For the same reason as above, make very sure you don't overwrite the CA key/certificate accidentaly.
When replacing the certificate for the apiserver you will need to restart the apiserver. The apiserver does not reread the certificate automatically.
Related
I have an enterprise issued certificate that I want to use to secure a WCF message channel. The certutil program tells me that both the CRL and delta CRL are valid (status = "Verified"). I'm using the sample WCF programs from (https://www.microsoft.com/en-us/download/details.aspx?id=21459); specifically the MessageSecurity.sln test. When I replace the self-signed certificate with the Enterprise CA-generated certificate, I get the error:
The X.509 certificate CN=localhost chain building failed. The certificate that was used has a trust chain that cannot be verified. Replace the certificate or change the certificateValidationMode. The revocation function was unable to check revocation because the revocation server was offline.
Has anyone got message based channels working with anything other than self-signed certificates (i.e. with a valid CRL distribution point)? Any ideas what to try next?
Fun fact! The client maintains a cache of CRLs. After properly configuring the CRL distribution point, the cache with the erroneous CRL locations prevented the WCF sample from running. When it magically started working two days later, I did some digging and found out that the lists are cached. You can clear the lists manually with:
certutil -urlcache crl delete
After using this command I was able to predictably and reliably use my Enterprise CA generated cert to establish Message and TransportWithMessageCredentials channels.
Shortly after we renewed our SSL certificate on Heroku, all Mailgun webhooks (post requests made by Mailgun to our endpoint so that we can track email deliveries) started failing with the error "Could not connect to remote server: HTTPS certificate validation failure".
How could we check whether this issue might be caused from misconfiguration of our SSL certificate rather than an issue on Mailgun's side?
Here are the details of steps we took to renew and install the certificate:
We followed these instructions to generate a new private key and
CSR.
After uploading the CSR and downloading the CRT file on Namecheap, we ran heroku certs:update as described here.
These are the checks we made to verify successful installation of the new certificate:
Navigated to our site with Chrome, Safari, and Firefox and checked
the certificates. Everything looks right.
Ran heroku certs. The certificate looks good and it is shown as trusted.
Used the online checker here and here (as watery suggested in the comments). Everything is green.
Verified with Namecheap that the intermediates were setup correctly. They basically confirmed that the output of openssl s_client -showcerts -connect www.mysite.com:443 looks right.
A potential lead:
After running brew update openssl and rvm install 2.3.1 --disable-binary, the following was observed. Running Net::HTTP.get URI('https://www.google.com') works, while the same command with our URL fails with OpenSSL::SSL::SSLError: SSL_connect returned=1 errno=0 state=error: certificate verify failed.
However, running Net::HTTP.get for our URL on a freshly installed linux Docker container
does not fail, so there may be additional environment factors.
Any leads to the likely cause of this issue, or suggestions for steps we can take to find such lead, are much appreciated.
The issue was found as described in my other related question. COMODO added a new root called COMODO RSA Certification Authority instead of the previous COMODO Certification Authority. The new root was not whitelisted by Mailgun. I contacted support, and they are working to whitelist it.
I think this is related to SSL chaining issue. Please check the ssl certificate you are using must be in order of domain_cert > root_cert > intermediate_cert(they can be multiple). You need to concat certificate in fixed order to fix this issue. I hope this helps you. For more you can test you website ssl in this https://www.ssllabs.com/ssltest/
I'm using an autosign script in Puppet to sign certificates. This is actually working, but I'm experimenting a problem when a machine try to request again a certificate (eg. ssl directory is removed). In this cases, a cached certificate is used and obviously does not match with the certificate created by the agent. Here is an example output:
Info: Creating a new SSL key for foo.bar.com
Info: Caching certificate for ca
Info: Caching certificate for foo.bar.com
Error: Could not request certificate: The certificate retrieved from the master does not match the agent's private key.
Certificate fingerprint: 41:B7:ED:3C:EC:A9:EF:A9:51:8C:6C:46:94:B1:30:09:72:2F:CC:D2:13:BA:A5:63:A7:2D:C5:FB:BD:DF:A5:B4
I don't want/can't remove certificates by hand executing puppet cert clean so I tried to use allow_duplicate_certs but seems to be buggy since... quite a lot time.
Do you know any other option to re-autosign a certificate when the host already have a signed certificate in the CA?
After changing ssl certificate authority from Thawte to DigiCert.
SSL certificate installation issue.
After installing new DigiCert ssl certificate in our server. It is still referring to old Thawte ssl certificate even though we removed old certificate from the server.
Looks like you have another vhost file using the old certificate , please remove that from your . Also make sure you properly restart apache after adding the new certificate .
To check your installation you can use the tool below
Thawte certificate checker
To see what certificate you are using, you can use the following tool Tool
This tool will allow you to check what certificate is installed on your server. Then, you can use the utility tool utility tool
You will be able to see all of the certs from your local machine or server. If you don't see the certificate there, you can import your certificate with that tool. If the utility tool mentions that your private key doesn't match, you will have to recreate the CSR with the utility tool and you will have to reissue your cert. If you reissue your cert, you will not invalidate the original request.
I updated the SSL cert on a customer server. The cert was about to expire.
The customer sent me the new cert in PEM format. I just replaced it on Apache and restarted it. The new expiration date is correct, but I got a little validation error:
Unable to get the local issuer of the certificate. The issuer of a locally looked up certificate could not be found. Normally this indicates that not all intermediate certificates are installed on the server.
The cert uses an intermediate cert. Maybe I need to update the intermediate cert too ? Using the old cert, this validation error don't occur.
All seems to be working perfect. Browsers don't show any error.
You need to update the intermediate cert too, if it is different, as it seems to be. You might also want to check that the CA (Certificating Authority) cert has not changed, or if it has, add the new one.