We have an existing SSL certificate for one of our domains which will expire next week. We know that actually there is no SSL "renewal" but we will get a new certificate instead, but we got stuck with an important question in mind.
We bought the new certificate from the same company as last year, and created a new CSR code and sent them. We wanted to complete the validation by adding a CNAME DNS record, but since there is already a CNAME record with the same name which we added last year for the validation of the existing SSL certificate, we have to actually modify the existig record.
Here our question is; will the existing old certificate be cancelled as soon as we change the CNAME record and they issue the new one? Because if that is the case, our website won't be reachable until we get the new certificate and set it up in the server, which will likely take up to an hour.
Thanks in advance.
Related
I've set up my app running on Cloud Run with a Let's Encrypt wildcard certificate to cover subdomains. It works fine, but everytime I run testssl.sh or other similar tools they notice 2 certificates: mine and Google's. The second certificate throws errors regarding name mismatch and from time to time (couldn't reproduce it, it may not be a problem) even browser notice this and say the cert is not valid, but a refresh will fix it.
Is this something common and should I ignore it? Google's DIG shows that the domain has the correct IP as A record and everything else works fine.
Use only one certificate.
A wildcard certificate with Cloud Run provides few benefits. Only domain names that are mapped will be supported so the wildcard does not help. The negative is that you must manually renew the certificate every 90 days.
Use the Google Managed certificates.
I had AutoSSL by Comodo on my CentOS WHM VPS previously configured and running. After the certificates got expired, I installed Let's Encrypt and tried to renew certificates via that service which failed with error that signified a DCV validation issue due to me to using the server's DNS. Also the HTTP validation was failing too.
Later, I switched back to Comodo AutoSSL and renewed two of the sites while all others failed with same error above.
Now the issue that persists is that I can't access the websites except one (the main account on WHM). All of the sites are showing defaultwebpage.cgi
What might possibly be the issue and what can be done to get the system back up?
Finally got the issue solved. The faults on my setup that made the DCV to fail were (different for different domains).
For a few domains, the DNS had AAA records(with IPV6 values) that prevented the updation.
For another domain the issue was that the DNS was on cloudflare and it wasn't getting auto updated. So, i had to manually enter the record that has name '_cpanel-dcv-test-record' and a value that had a data like '_cpanel-dcv-test-record=UF0zA7G97dxugw_u10XVpkRJ0faQg2bk2UHf2vDJkhKcElawaQqyaLtCL3VsquAGxv' (sample values for reference. not real)
I made the above changes, selected the domains (Inside CPanel for individual account > SSL > SSL Status) that needed the change and pressed the 'Run Auto SSL'.
Hope this helps someone who goes through a smilar situation.
My wildcard certificate expires in three weeks and I've just renew it and installed the new certificate, so that my IIS has two now.
I have currently more than 30 sites running and I would like to update them one by one to use the updated certificate. Though I dont see a parameter for appcmd set site which allows me to specify which certificate to use. I really would hate to have to delete the old certificate and re-add all sites asap which means my sites would be without SSL for a few minutes.
Seems like there were no other possibilities, I decided to go ahead and update them manually as quickly as possible. When entering the "Bindings" popup for the first website, it warned me (as usual with https bindings) that multiple sites were detected. I ignored the warning and set the new certificate for the first website. That also updated the https bindings on all the other sites apparently. I have checked with various online SSL checkers and the sites all seems to be updated now. Phew.
I am using a Debian/Apache webserver with up-to-date software and a SSL certificate to encrypt the communication via HTTPS. In February the old certificate expired and I got me a new one (CA Geotrust via CA RapidSSL). Like the one before.
In Firefox (Chrome, ...) everything works fine. But after the old certificate finally expired after 2 weeks, Internet Explorer says the certificate has expired - leave the page? Appearently the old certificate is stuck in the browser cache and has not been updated since.
And the thing ain't done with clearing the browser cache. I actually had to reset the IE settings to make it reload the new certificate. As it works by now, I guess that the server delivers the correct certificate. But there are still other users who report the same problem - so it wasn't my browser alone.
My best guess is that something in the old cert or my cache suggestions told the IE to store the certificate for a long while. But I have no clue how to solve this - or even what to change so I don't have the same problem next year, again.
Thanks for any ideas!
BurninLeo
I had a similar problem. In fact it is IE under XP who don't support several HTTPS subdomaine on a single IP address.
http://nginx.org/en/docs/http/configuring_https_servers.html#sni
So if you have also several domains or subdomains in same IP you can't solve this on XP/IE you can just choose which certificat is used by XP/IE but it will be the same for all subdomaine.
PiR
I currently have a wildcard SSL certificate running on IIS 6 and needs to be renewed. The new certificate bit-strength is now 2048 (the current one that needs to be renewed is 1024). Is there any easy way to get a certificate request file that is 2048 bit when renewing from a 1024?
I don't see the option to change bit strength for renewing an SSL certificate (I only see this when creating a totally new one from scratch).
I recently had to do this very same thing, and the way I did it was I had to remove the current certificate completely, then add a new certificate fresh, otherwise, I could not figure out how to update the CSR from 1024 to 2048, which is now a requirement.
So, to answer your question, remove the current certificate first (this might be tricky if it's a busy online store), then go through the wizard and switch the CSR from 1024 to 2048.
Not the best answer, I know, but the only one I could seem to find right off (and the easiest)
Be warned about trying to get clever with this one. I just got myself in a big mess trying to do exactly this same thing without any downtime.
What I did was :
create another website and generate a cert request for that. made sure to put in the correct common name when generating the request.
I downloaded the certificate that was generated and installed it in my 'Personal' certificates for the Local Computer account (after adding certificate snap in).
Did 'replace' on the main website for the certificate and chose the new updated one.
I ended up getting this error (as reported by Chrome) when accessing the https site.
(net::ERR_SSL_PROTOCOL_ERROR): Unknown error
After playing around and switching back to the original certificate I ended up just removing it and re-keying the certificate. It only led to 1-2 minutes of downtime.
I do think that if you do what I was attempting in the correct order you'd be fine. I think you need to export the .pfx file and then import that. I think whats happening is the original server didnt have the correct private key or something like that and was getting confused.
So I'm upvoting calweb :-)