I'm using certbot with letsencrypt to generate ssl certificates for a few subdomains on a few sites. The certs are generated using the --manual flag with a DNS challenge.
It's now time to renew a dozen or so certificates, is it possible to do this without changing the certificate body itself, or is the expiration date built into the certificate itself?
My goal is to manually renew a bunch of certs without having to redeploy the servers.
The expiration data is part of the certificate. Just look at the cert with a text editor and you will see this.
with longer expiration dates. If what you want to do was possible the expiration data would be worthless.
To get around this purchase certificates with longer validity.
Note: Effective March 1, 2018, CA/Browser Forum Baseline Requirements restrict the maximum validity of DV and OV SSL certificates to 825 days. The change goes into effect March 1, 2018 and affects all CAs and all types of SSL/TLS Certificates. See GlobalSign.
Related
I did a scan of my domain using ssllabs.com, and this is what it says:
From what I can tell, one of my CAs is USERTrust RSA Certification Authority, and their certificate is expired, which SSLLabs flagged red, but it still says that there are no chain issues, and no browsers complain about talking to my domain.
I did the check after curl was complaining about an expired cert when talking to my domain, which may or may not be related.
What's going on here? How can an expired CA certificate not be a problem?
The expired certificate is actually not used for validation. It is unnecessarily send by your server, i.e. you could remove it from the certificate chain you send since modern system have a trusted CA builtin which effectively replaces this expired intermediate CA. For more details see for example USERTrust Intermediate Expiration in 2020. To cite:
This is an old intermediate certificate and modern operating systems have a new version available and won't be affected. ... Based on what we know, equipment released or receiving security updates after June 2010 will most likely not be affected. ...
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.
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.
I have received a wildcard certificate from AlphaSSL.
The CSR was generated in CPanel. The SSL CRT is being accepted in the SSL manager console for CPanel.
As Android and some other devices do not validate the SSL certificate on it's own, it needs further addition of the CA Bundle / Intermediate Root Certificate to the server.
The intermediate certificate was supplied in the confirmation email, but fails to install to the server.
When I paste this into the CA Bundle field, it states the "The CA Bundle does not match the certificate".
It seems that AlphaSSL & Globalsign made a major update to their intermediate root certificates as of the 31st March 2014 (last week).
A lot of SSL resellers have not yet updated confirmation emails, and are providing outdated intermediate root certificates (last updated in 2011) which will not work.
Also in a lot of support web pages, references are made to these same old certificates.
Hopefully resellers will update their systems in coming weeks/months.
However should anyone else have problems with this, you can get the latest Root Certificates directly from the following links...
AlphaSSL :
http://www.alphassl.com/support/install-root-certificate.html
Globalsign :
https://support.globalsign.com/customer/portal/articles/1426602-globalsign-root-certificates
Simply remove the CA Bundle text and run installation. Because In most cases, you do not need to supply the CA bundle because the server will fetch it from a public repository during installation.
Here is my situation:
I have a client application that I'm going to distribute - we'll call it MyClient.
MyClient does some SSL communication with one of our servers.
MyClient has the root CA embedded in it, so it can do proper verification of the server certificate.
Now, suppose some years go by, the root CA expires, and is renewed.
Does that mean I need to patch MyClient in the wild?
In other words, will a change to the validity dates on the certificate cause it to no longer match the baked-in root CA in MyClient?
Addendum: Suppose I write my client to not validate the date of the cert (but everything else). Then, when the root CA expires and is re-issued, do I still need to patch? Will other parts that play into the validation change, other than the date?
If your client is ensuring an SSL server certificate is issued by a particular root CA and that root CA is included in the client then yes, you will need to patch your client to replace the root CA certificate.
There are few good ways of doing this. What tends to happen is that root CA certificates are very long lived and use shorter lived intermediate CAs to issue SSL certificates but it sounds like this is not the case here.
Looking on the bright side, I do not know what algorithms were used with the old root CA certificate but, hopefully, The new root CA certificate will hopefully use a larger key (2048-bit RSA rather than 1024-bit or 512-bit) and a better hashing algorithm (SHA1 or better rather than MD5) so it may be a good opportunity to increase security.