I had a server and host some sites on it
I used letsencrypt (certbot) for creating and renewing certificates for these
I took another server and moved the sites to it
And created new certificates for these sites on new sever by letsencrypt
Now I get emails from time to time "Let's Encrypt certificate expiration notice for domain..."
I look in a browser and certificates are valid for a couple month
I suspect that the emails are talking about certificates from the old server (I no longer have access for it)
How I can look all certificates that bound with my email and delete some of these?
Related
I'm fairly new to the whole certificate shebang and not a versed Linux admin.
In our company, we run a Windows domain, but we also have some CentOS servers for different services.
On one of said servers we have our ticket system, which is browser based. I want to certify it with a certificate, signed by our Windows root CA, but no matter what I do, the certificate is shown as invalid in the browser.
Funny enough, both certificates in the chain (CA -> server) are shown as valid.
I already did the following:
start certificate process from scratch
tried different certificate formats (.cer, .pem)
verified server cert with root cert
checked validity with openssl (OK)
checked SSL connection with openssl, no issues
added root cert to Linux server trusted CA store
recreated cert chain (of 2)
restarted Apache over and over
reset browser cache
tried different browser
checked DNS entries
checked, if root CA is trusted in Windows (it is)
manually installed server cert in my browser
Both the server cert and the root cert show up as valid in the browser, with the correct relation.
I'm completely lost here. Is there some key step I forgot and not one of the ~30 guides I read forgot to mention?
Any help is greatly appreciated
Your question is missing some information:
Did you check the SSL connection from outside the server?
Did you verify the RootCA cert is inside the cert-store of the server (sometimes it is rejected without error messages)?
I would check the reason for rejecting the certificate in the browser (FireFox is usually more informative than Chrome), and look for the error-code.
Reasons can be (some of which you have already verified):
Wrong certificate properties (missing the required values in the "usage" attribute)
Wrong domain name
Expired certificate
Certificate could not be verified on the client-side
See this image as an example of an error code:
https://user-images.githubusercontent.com/165314/71407838-14f55a00-2634-11ea-8a30-c119d2eb1eb1.png
I have been managing Let's Encrypt's SSL certificates for a domain.
Now I am moving to Amazon API gateway. I will be using the AWS Certificate Manager to generate HTTPS certificates for the root domain and a bunch of subdomains.
If I make the transfer, what happens to my current HTTPS certificate which is associated with my domain. If browsers suddenly start seeing a new HTTPS certificate for a domain, for which they had been getting a different HTTPS certificate until now, would this be a problem?
Also, once I make the shift, what do I do with my current (manually managed) Let's Encrypt certificate? Is there a way to permanently void it?
Szabolcs Dombi says
You can have multiple valid certificates for the same domain at the
same time. Moving from one certificate issuer to another should not
cause a problem.
Toby Osbourn says
SSL certificates don’t last forever, most of them need to be renewed
on a yearly cycle and occasionally you will want to change the type of
the SSL certificate mid-cycle.
Since you are replacing certificates, I suggest you to back up the ones you have.
Once you have backed up the old certificates, just overwrite the .crt and .key files with your new ones. Then, reload your web server so it knows to look at these new certificates, and you should be good to go.
If it's within your interest to know more about how to Generate SSL certificate using Amazon Certificate Manager (ACM), I suggest Barguzar, A. (July 2018). Building Serverless Python Web Services with Zappa. where one can read a good step by step guide. See an excerpt of it below:
ACM is a service that manages and creates SSL/TSL certificates for
AWS-based services and applications. An ACM certificate works with
multiple domain names and subdomains. You can also use ACM to create a
wildcard SSL.
ACM is strictly linked with AWS Certificate Manager Private
Certificate Authority (ACM PCA). ACM PCA is responsible for validating
the domain authority and issuing the certificate.
You can have multiple valid certificates for the same domain at the same time. Moving from one certificate issuer to another should not cause a problem.
This also means that if you create a new certificate the old one still can be used unless it already expired.
I'm developing an app for a non-tech client that has outsourced the backend to another developer. We'll be launching the app under 7 different branded app, over a series of weeks. Each app is exactly the same, sans for the domain the API end points are on (IIS hosted).
As part of our security, we validate the SSL certificate when we connect to the API, and ensure the key returned by the API server matches our hardcoded version of it, as to prevent man-in-the-middle attacks to sniff our REST calls. We have this functioning now for the current server (1 of 7 to be rolled out).
We've asked the backend guys to provide the certificates for the remaining 6 sites, so we can deploy the apps with the expected keys. However, they claim that as they will be rolling out the sites individually over the coming weeks, each time they bring a new a new site online, they said they are "updating the SSL certificate" which is required as they are "using SNI on the server, so each time a new site is added, the certificate will change, and the hardcoded validation for the existing sites will break".
Now whilst I'm no dummy, I'm also not a server admin, and only 99.9% sure that the SNI configuration to support another cert on the server, will not have any affect on the current certs already hosted for the existing domains. As a result, I wanted to explicitly confirm that the cert key we're validating as part of the SSL auth, is not going to change with each revision of the SNI config. The backend devs have essentially shut us down claiming we're paranoid, and going "beyond what is required" and to not expect "the same security a the major players offer" (as I mentioned that any decent commercial app validates its connection).
Is anyone able to confirm (or correct) my understanding of SNI as it relates to the certs, primarily that as they bring new sites online, that changes to the SNI have 0 impact on the existing certs for the current sites?
Edit: Whilst the use of multi-domain certs would regenerate the key, we can assume that they could generate/re-issue a multi-domain cert now in advance of the domains coming online. The question of if it's affected by the SNI config remains.
"updating the SSL certificate" which is required as they are "using SNI on the server, so each time a new site is added, the certificate will change, and the hardcoded validation for the existing sites will break".
This is a weird argument. The point of SNI is that they can have multiple sites (domains) on the same IP address where each has its own certificate. If they add a new site only a new certificate for the new domain need to be created and all the other certificates will continue to work: a client using SNI will tell which site it wants to visit and the server then can pick the appropriate certificate. If they instead could not rely on SNI then they would have to use certificates which cover all sites on the same IP address.
So while it can be that they have some process which requires this kind of reissuing certificates it is not a requirement because of use of SNI, but only because they designed their process this way.
I followed all the instructions to get a SSL certificate from Let's Encrypt for my website, but two hours after I successfully got the message "Your certificate and chain have been saved", I still cannot access my website with HTTPS and get the error "the website refused the connection".
Do you know how much time is needed to activate the certificate?
On the web hosting offer of OVH, the HTTPS protocol is available after the deployment on all the load balancing infrastructure. It take around two hours.
You can check your "multisite". Maybe your website doesn't have the "SSL" flag enabled and the generated certificate do not handle your website.
I have been using a wildcard SSL certificate for several of my company's B2B websites for some time. Recently, we noticed that Google Chrome started displaying a red unlocked lock with HTTPS crossed out for all of these websites. The solution I found was to reissue the certificate from the provider (Network Solutions). So, I did this, and updated the certificate for each of the websites, and the Google Chrome issue went away (HOORAY!). However, when visiting any of these websites in Firefox, it displays a security message stating the website is using an invalid security certificate:
How can I resolve this so that our users are not confused when visiting these websites?
P.S. These websites are running on IIS6.
It looks as if the certificate chain is incomplete and, thus, Firefox (and likely other browsers) cannot verify the site certificate. Normally browsers store intermediate certificates they have seen in the past - that might be a reason why it works in Chrome.
You can test using https://www.ssllabs.com/ssltest/analyze.html.
Depending on the server software (here, for Apache httpd and other servers which read the certificate in PEM/DER format), you can just paste the intermediate certificates together with the certificate in one .pem file (which is used as Certificate file).
The chain (intermediate certificates) is/are normally provided by your CA. In your case you could also use Chrome the review the certificate and then store/extract all intermediate certificates from the certificate view.
You can get this certificate is not trusted error if server doesn't send a required intermediate certificate.
Firefox automatically stores intermediate certificates that servers send in the Certificate Manager for future usage.
If a server doesn't send a full certificate chain then you won't get an untrusted error when Firefox has stored missing intermediate certificates from visiting a server in the past that has send it, but you do get an untrusted error if this intermediate certificate isn't stored yet.
You can inspect the certificate chain via a site like this:
http://www.networking4all.com/en/support/tools/site+check/
I followed the instructions at enter link description here, to import the intermediate certificates.
In IIS, there is an option under Directory Security to "Enable certificate trust list". I enabled it and added the "AddTrust External CA Root" to the CTL certificates list and this appears to have fixed the issue.