For performing client certificate authentication(SSL) at server side for revocation, we can add property crlFile in tomcat connector. But this process is static means if the crlFile in that location updates, tomcat wont pick new CRLs it still binded to the old CRL file. Tomcat needs restart to pick the new changes in CRL file.
I have two questions here,
1) How to make the above process dynamic( If CRL file in that path is updated, pick the changes without any restarting) ?
2) How to get updated CRL files from CA timely and where to configure CDP(CRL distribution point) in tomcat so that if CA updates CRL files it downloads the file( which have some expiry time) to local machine(server) ?
Related
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.
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.
via Namecheap I have my SSL certificates (POSITIVESSL Comodo) which run on my Nginx webserver to offer https to my clients. This worked like a charm until my certificate expired.
Now I tried to install a new certificate, but whatever I try, the old one is being loaded.
What I did.
Removed all the old certificate files (.key, .crt, .csr)
Using this tutorial creating a new key files.
Entered that file into the Namecheap SSL panel to generate new SSL certificates (which arrived, and show to be valid from 11/26/2012 to 12/26/2013.
Go to my certificates directory, put in the 3 .crt files I got.
Using this tutorial i bundled all the .crt files into 1 .pem file.
Check my nginx.conf to confirm all the paths to the .key & .pem file are correct
Restart nginx
I even tried to change the file names, to ensure they cannot conflict with the old ones, but still my old certificates are being loaded. I have used tools like: http://www.digicert.com/help/ to test the certs, also there the old ones are still being loaded.
Apart from Nginx, should I restart anything else to ensure the new files are being loaded correctly?
Issue has been resolved, the DDOS protection proxy also needed to be updated.