ZeroSSL credits (rthese same domain, but I cant' renew) - ssl

I have a expiored in some days SSL cert in zeroSSL panel, but I cant't renew it becouse I have 3/3 certificates generated. 1 is still active, but other two is Expired (it has been generated early for these same domain). Is it possible to delete somehow one of them and renew existing in these same free acoount?

ZeroSSL provides 3 certificates for each free account.
The free certificate quotas are not including lifetime renews service.
It can be generated once and can't renew.
You can create a new account with a new email address (I recommend using Temp Mail for unlimited temporary email address.) to obtain extra 3 new certificates.

If you are no dedicated hosting. Certbot will help you to install and renew the SSL certificate automatically. Visit Certbot instructions to know more. It allows you to install free SSL certificate.

Related

How to use existing certificates from kube-lego after migrating to cert-manager?

I've been pretty happy with kube-lego which manages thousands of certificates for me. I'm now migrating to cert-manager, it's successor, but in my test deployment, I noticed that when cert-manager saw an existing certificate with 33 days left til expiration, it replaced it with a new one even though it didn't really need to.
I'm worried that when I flip the switch from kube-lego to cert-manager, cert-manager will flood Let's Encrypt with thousands of certificate requests all at once. I'd prefer if cert-manager used the existing certificates, previously managed by kube-lego, until each certificate gets closer to its expiration date because it will space out the certificate requests more evenly.
Is it possible to tell cert-manager to use the existing certificates and not request new certificates?

Issue with www.google.com SSL cert in WebSphere 6.1

I'm adding Google reCaptcha v3 to my J2EE application that runs under WebSphere 6.1. (I know, its no longer supported. A software upgrade is on the plan, just not immediately.)
I've followed the steps below to add the www.google.com:443 cert to WebSphere's NodeDefaultTrustStore, and after restarting WebSphere, the SSL cert is accepted no problem. My servlet code that does the reCaptcha verify logic works fine and all is well.
However, the following day, the certificate I imported is no longer accepted. When I import it again, I see that the Fingerprint (SHA digest) is different than the previous day. It looks like Google changes their SSL cert on a daily basis. Is this true? If so, how do I get around this problem in WebSphere?
CWPKI0428I: The signer might need to be added to the local trust store.
You can use the Retrieve from port option in the administrative console to retrieve the certificate and resolve the problem.
If you determine that the request is trusted, complete the following steps:
Log into the administrative console.
Expand Security and click SSL certificate and key management.
Under Configuration settings, click Manage endpoint security configurations.
Select the appropriate outbound configuration to get to the (cell):ServerNode01Cell:(node):ServerNode01 management scope.
Under Related Items, click Key stores and certificates and click the NodeDefaultTrustStore key store.
Under Additional Properties, click Signer certificates and Retrieve From Port.
In the Host field, enter www.google.com in the host name field, enter 443 in the Port field, and www.google.com_cert in the Alias field.
Click Retrieve Signer Information.
Verify that the certificate information is for a certificate that you can trust.
Click Apply and Save.
"Retrieve from port" adds the leaf certificate. To do something more reliable, trust the issuer. The current issuer for is GlobalSign root CA R2 which you can grab from https://pki.goog/ (GS Root R2)
Unfortunately it is hard to automate grabbing the root CA in tools like "retrieve from port" because many SSL toolkits do not send the root CA over the wire during the handshake -- because the client should already have it.
Here's an approach for WebSphere Liberty that might work for 6.1, I haven't tried it.
https://www.ibm.com/support/knowledgecenter/en/SSEQTP_liberty/com.ibm.websphere.wlp.doc/ae/twlp_add_trust_cert.html
Use the openssl method but take the -second- certificate in the list (which doesn't expire until 2021).

SSL for custom client domains

I have an app (hosted in heroku) where customers have an individual subdomain e.g. client1.myapp.com, client2.myapp.com I am using a wildcard SSL cert here.
If however a client wants to use their own custom domain e.g. CNAME app.client1.com
How can i automatically provide an SSL cert (I'm guessing using Lets Encrypt) for the client without them providing me a certificate to upload in a similar way to firebase etc.. provides SSL certs for domains.
As long as app.client1.com is reachable from the internet, you are free to set up a lets-encrypt certificate.
If your applications run on unix-like system, then the cerbot docs describe all the steps for automating the renewal.
You basically have to set up a cronjob that launches the renewal command.
You can edit the crons in you linux machine with the command crontab -e and place something like this at the end of the file:
0 15 1 * * certbot renew
This will run the command the first day of each month and attempt the renewal of your certificate. Check crontab.guru if you need different settings.
If you want to call the cerbot command from a custom script, you can add such script to your cronjob (and save the output to a custom file).
E.g:
0 15 1 * * python cert_autorenew.py >> cron.log 2>&1
Keep in mind that if you want a certificate for app.client1.com, then the renewal request you send, must resolve to the server app.client1.com.
That's how you demonstrate the control over your domain to letsencrypt.
If you are hosting the new application in Heroku/new domain is directed to Heroku app, they will take care of the SSL Certificates for you, as long as you run the application on a paid dyno. Which you should as its a client's application!
https://devcenter.heroku.com/articles/ssl
Heroku provides free Automated Certificate Management (ACM) for all
applications running on paid dynos. With ACM, Heroku automatically
provisions and renews SSL certificates for your application. If you
prefer to upload your own certificate manually, follow the steps in
this article.
You only have to make an application in Heroku, upgrade the dyno and configure the custom domain name (app.client1.com) for the application, following instructions at https://devcenter.heroku.com/articles/custom-domains

ssl on custom domain for heroku app

I want to connect a custom domain to an app built on Heroku. Can someone confirm that I actually need to buy a certificate and in addition buy the SSL addon on Heroku?
Do I need both or is one of them enough? What is the point of the addon?
/Knut
If you are already using paid dynos (e.g. Hobby dynos) then you can save some costs by using Heroku SSL for free in your app, instead of paying for the SSL Endpoint add on.
This is assuming your app doesn't need to support really old browsers (see Minimum supported browser versions.
These add ons basically provide the protocol support your app needs for SSL with your private domain.
However, regardless of which of the above 2 you choose, you will still need to acquire in addition an SSL certificate. There are all kinds of different offerings for the actual certificate, including free certificates e.g. from Let's Encrypt.
See here for instructions on using a free Let's Encrypt certificate on Heroku with Heroku SSL.
Bottom line: If you are already using paid dynos, it should be possible for you to add full SSL support for your custom Heroku domain for free.
If however you find the above too bewildering, you might want to pay a few bucks for a service such as Expedited SSL, which gives you a certificate (for a monthly fee) and takes care of the whole issue of installing it and keeping it updated on Heroku.
Heroku has made it even easier to use SSL for custom domains now assuming you're not on the free tier plan (if you pay for at least one dyno you're good to go).
https://blog.heroku.com/announcing-automated-certificate-management
Basically, once you have a paid plan for your app., Heroku will generate the certs for you and any custom domains you have added. Then you need to check that you have the right forwarding setup by your domain provider etc.
To add ssl to an existing app you can run:
$ heroku certs:auto:enable -a <app name>
Then run the following command and make sure your custom domains are returned:
$heroku domains

Can I create an SSL cert for a server that doesn't exist yet?

Someone just asked me to create an SSL certificate for a server that hasn't been created yet.
In fact, it's going to be hosted, so I won't even have a linux account to ssh into it.
Normally I would create the CSR on the server, and then send it to a registrar like Thawte.
Does this request make sense ? Is it possible to create an SSL cert without having ssh access to a server ? Or is my boss not understanding the process?
For web server running over https protocol, the important component of SSL certificate is the subject's CN field. This field is matched by browser against the DNS record to verify the web server is indeed whoever it claimed to be
You can purchase a SSL certificate without physically provisioning the server. However as part of purchase procedure the CA will perform domain ownership verification (and more rigorous vetting if you purchase OV/EV certs)
It doesn't matter where (physically) the command to generate private key and issue CSR is executed as long as the final product is installed once the server is provisioned
Furthermore, repointing the DNS record to different server doesn't require new cert to be issued. The important thing is you decide on DNS entry name.
Yes, you can create the CSR (PKCS10) on a different server than the one you install the certificate on. Just make sure you get the whole pfx back, with both the private and public key. However, it will now work if you have a HSM, as the private key will be stored in the HSM, and not be transportable.