I have an old kubernetes cluster on v1.8.6, using kOps I have been trying to upgrade the server to v1.20.8.
I run into a CA cert/key issue where kOps was failing to rolling update the cluster returning an error x509: certificate signed by unknown authority.
kOps had created a new ca secret, so there were now two secrets with type ca. Looking through github issues I found what sounds similar to what I was experiencing and I removed the old ca cert/key with kOps delete secret .... thinking I would move forward with the new one only.
I didn't take a backup of the key, I did get a copy of the crt from S3 but also from my local .kube/config and the master servers ~/.kube/config has the same certificate-authority-data. I can connect to the cluster again with tls via kubectl, but kOps is having issues. There are no ca .crt or .key files in my kOps state store on S3.
Can I restore the key file somehow?
Can I create a kOps secret in this case without the key file, if I plan on upgrading the cluster anyway?
If you have not rotated the control plane/master nodes, you will find the certificates on there. The location for those files have changed over the years, but you should hopefully find them in /srv/kubernetes/.
Or you can restore them if you have enabled S3 versioning.
kOps will reprovision any lost secrets next time you run kops update cluster --yes. You can stick with the new certificates, but then be aware you are effectively doing a key rotation and may want to follow the remaining steps mentioned in this document.
Related
I have a kubernetes cluster and I've been experimenting so far with cert-manager and letsencrypt ssl certificates.
Everything goes fine, I have issued an SSL certificate and applied to the cluster and https connection is working excellent.
The problem I face is that I am experimenting with new things and it often leads me to delete the whole cluster and create a new fresh one, which on it's side makes me lose the SSL certificate and issue a new one, but there's a rate limit by 50 certificates per week per domain.
Is there a way I can reuse a certificate in a new k8s cluster?
Copy the secret locally (kubectl get secret -o yaml and then clean up unneeded fields) and then upload it to the new cluster (kubectl apply).
I have purchased ssl certification for my website. As an initial process, I have created a CSR and KEY file and presented it to the certification provider. Upon receiving the certification, I have copied all the files including the .key, .csr, .crt files into a folder by name certs.
While removing unnecessary files from the drive, I accidentally deleted the certs folder also. I have the .crt files in my local machine, Can i retrieve the .key file and the cert folder.
I tried using extundelete and used the following command.
sudo extundelete --restore-directory /home/ubuntu/certs /dev/sda1
I don't understand the /dev/sda1 part. Is there any chance where I could retrieve the files? The folder was in EC2 Ubuntu instance.
Please help.
Forget the old certificate and get new free one via https://letsencrypt.org/
I have installed LetsEncrypt on Ubuntu 16.04 Apache server. It generated 4 .pem files under its letsencrypt/live directory. I am using the public and certificate pinning mechanism and dumping them into the iOS app bundle. To avoid updating the app on renewal i have read that it has to be renewed using a --csr flag but couldn't get much help on this. Can letsencrpyt renew the way i want to or i need to use some other client? Do i have to regenerate all the certs as am sure it generated only pem and no csr files while creating certificates with Letsncrypt. Thanks.
The csr generated by LE can be found out in /etc/letsencrypt/csr. I picked the latest csr file (usually the one which has the highest integer is the latest, e.g.: 0005_csr-letsencrypt.pem will be latest to 0004) and renewed the certificate with the above command:
letsencrypt certonly —csr /etc/letsencrypt/csr/0005_csr-letsencrypt.pem
This will generate 3 files called in the same directory:
000x_chain.pem - has same PubKey but new expiry (what we need)
000x_chain.pem - has some CA information
000x_cert.pem - the cert which will match the PubKey of the cert
I used the 000x_cert.pem for my app bundle. So every time i renewed the certificate i could hit the server even though i dont replace the 000x_cert.pem in the app. It works as the public key will be same. Thanks.
We are using Puppet to configure multiple clusters running Apache HTTPD using the Apache module from Puppetlabs.
All certificates are stored in a git repository Puppet has already access to (e.g. puppet://files-host/path/to/certs/${fqdn}.crt).
Right now we have to explicit specify the intermediate CA certificate (ssl_chain variable in the apache class) for each used certificate.
Is it possible to let Puppet automatically find out the correct intermediate CA certificate? In a "real" scripting language I would iterate over all *.pem files and compare the subject with the issuer of the certificate. But how could that work in Puppet?
We do not want to embed the intermediate CA certificate into all certificates.
I've got a solution for my problem. It's not the optimal way, but it seems to be the only one in case of a Puppet managed infrastructure.
All intermediate CA certificates are located in a single directory in the git repository and Puppet will put the whole content of the folder to the managed hosts (set the "recursive" and "purge" attributes of the file resource to true).
Each certificate and key file is also deployed using file resources. The file resource for the certificate file will notify an exec resource executing a shell script which symlinks the right CA certificate to a static file path (i.e. /etc/ssl/private/my-domain.pem -> /etc/ssl/ca/some-ca.pem. So there are three files for each FQDN (fqdn.crt, fqdn.key and fqdn.pem).
I have just copied a SSL certificate (generated via let's encrypt certbot) from one server (A) to another (B). So, I have created a custom directory in my new server, let's say /home/my-certificate/, and copied the fullchain.pem and privkey.pem from (A) to (B). Everything works, the server is alive, the certificate are OK. Now I want to enable auto-renew on the new server (B). How can I do that?
Two good options stand out
Copy the Let's Encrypt certbot metadata from A to B as well, then install and continue to use certbot to renew as usual. This metadata is kept in /etc/letsencrypt/ and it tracks how your certificate was issued, from which certbot will conclude how it should renew it.
OR
Install certbot and perform a fresh certificate request on B, any time between now and when the existing certificate would expire. Assuming the certificate is for the exact same list of FQDNs this will only count against the per-certificate limit of 5 such requests per week, which is fine unless you're going to do this transition every day or you keep screwing it up and having to try again.
You need to copy letsencrypt renewal config to the new server, and then modify nginx config to point to the new, custom location: /home/my-certificate/
I would suggest moving your certs to the exact same location on the new server, in this case, you can just copy and paste certs and config without any modification.
Here is the list of steps:
Archive certificates on the old servers
Move them to a new server
Extract to the correct location
Create symlinks
Redirect domain
Based on this article
In addition to Druss's answer, a few more steps to be followed.
The solution provided will encounter problems when you try to renew the certificate.
To resolve this issue, a new certbot account should be registered, and conf file should be edited pointing to the new account. I followed the steps provided in this link.