I am using cert-manager ACME workflow to manage my certificates in K8s. Seems like cert-manager does not give me control on when the certificate gets re-issued (usually happens when expirations comes near).
Does cert manager revoke the previous certificate once it has issued the new one? And can you control this behaviour?
I tried looking for it in documentation, couldn't find the answer. Next up is an experiment.
Cert manager will renew certificates generally when there's 30 or less days left on the validity. It does not "revoke" older certificates, it renews them (where applicable)
The exception to this is if you change the hostnames on the certificate. Certmanager will issue a NEW certificate containing the updated names, but it will not revoke the old certificate. The old certificate will simply just not be renewed and will expire naturally.
Related
I have an ES Cluster(ES version 7.4.2) that has been running for 3 years.
when I run the following query.
GET _ssl/certificates
I'm getting the output.
"expiry" : "2022-11-20T07:27:29.000Z"
in /usr/share/elasticsearch
For the new 'temescls01-ca.p12' certificate
I run './bin/elasticsearch-certutil cert --ca /etc/elasticsearch/certs/temescls01-ca.p12' and when I enter the 'CA CERT password' it generates a new temescl01-ca.p12 certificate.
For the new 'temescls01-certificates.p12' certificate
I run './bin/elasticsearch-certutil cert /etc/elasticsearch/certs/temescls01-certificates.p12' and enter the 'keystore password'.
I'm using the old certificates' passwords for both new certificates.
I was able to create all 2 certificates. But when I stop the elasticsearch service and replace the old certificates with new certificates by following the document here, the node cannot join the cluster. When I replace the old certificate, the node joins the cluster without any problems.
An example from elasticsearch.yml
elasticsearch.yml
xpack.security.enabled: true
xpack.security.transport.ssl.enabled: true
xpack.security.transport.ssl.verification_mode: certificate
xpack.security.transport.ssl.keystore.path: certs/temescls01-certificates.p12
xpack.security.transport.ssl.keystore.password: XXXXXXXXX
xpack.security.transport.ssl.truestore.path: certs/temescls01-certificates.p12
xpack.security.transport.ssl.truestore.password: XXXXXXXXX
Is there something i did wrong?
It’s not possible to extend the expiry date of a certificate. But you can create a new one. If you are using PKCS #12 format of SSL/TLS (p12) certificate you can use this article to create a new certificate.
https://medium.com/p/99820ff87615
We have a reporting application which needs JKS file to be created from public certificate and private key associated with the certificate.
For our K8S deployment through Jenkins, we create this application and during this application deployment - pods, svc, ing, certificate also gets created and once our deployment is successful we call another script to use the certificate and private key, create a JKS and copy it to the pod in some location where application can pick it up. This works well but how do we automate this JKS creation and copy it to the pod with every let's encrypt certificate renewal since the certificate is renewed for every 90 days.
Posting an answer from comments.
After some comments, main question was narrowed down to:
"How to renew certificate manually using CertManager?"
Answer itself:
There's a CLI tool for CertManager which is called cmctl.
And it supports manual renewal of certificates by issuing following command:
cmctl renew $CERT_NAME
My application implements SSLPining with leaf certificate. And it's about to expire.
I researched and got the answer:
Some time before the certificate expires, release a new version of your app with a replacement cert in the pin list, as well as the original cert
How can i add both replacement cert and original cert to my project?
I just need to add a new certificate with any name and Will Alamofire go through all the certificate files I declare and if any match will it allow the connection?
Thanks
Yes, that will work. Alamofire's PinnedCertificatesTrustEvaluator gathers all certificates from the main bundle by default and checks to see whether the certificate received is within that set. So as long as both certificates are within that set, either of them should work.
I am currently working with SSLSockets and I want to create an application that will be released to the public - for example an android app, iOS app or similar.
I have a domain which is secured by an SSL-certificate. Is it safe to generate a keystore from that certificate and insert it into the project-jar and pass it to the user? Is the keystore still valid when the ssl-certificate has to be updated?
You already got the point, if you create a trust store with the leaf certificate (the certificate used by the server) in it you have to update it every time the certificate is updated on the server (depending on the used CA every 3-12 months).
Therefore the common solution is to include the intermediate or root CA certificate as those certificates typically have validity time of up to 10 years or more. If you include intermediate or root CA certificate you don't have to update the app if just the server certificate is renewed by the same CA.
I need to rotate admin.conf for a cluster so old users who used that as their kubeconfig wouldn't be allowed to perform actions anymore.
How can i do that?
This is a Community Wiki answer, posted for better visibility, so feel free to edit it and add any additional details you consider important.
As mdaniel wrote in his comment:
the answer to your question is "rekey the entire apiserver CA
hierarchy" or wait for admin.conf cert to expire, because those
admin.conf credentials are absolute. Next time, use the provided
oidc mechanism for user auth.
For kubeadm based kubernetes cluster please also refer to Certificate Management with kubeadm. For manual rotation of CA Certificates, please refer to this section. Pay special attention to point 7:
Update certificates for user accounts by replacing the content of client-certificate-data and client-key-data respectively.
For information about creating certificates for individual user
accounts, see Configure certificates for user accounts.
Additionally, update the certificate-authority-data section in the
kubeconfig files, respectively with Base64-encoded old and new
certificate authority data