I'm trying to configure SSL certificate with Let's Encrypt, but after configuring, some customers complained about "Privacy Error", specifically, one error was ERR_INVALID_CERT.
Most of the complaints came from Chrome on Android.
Windows 7 and up rendered green bar.
Windows XP SP3 - rendered the error, but after manually importing the certs to the customer's PC, it rendered green.
My setup is on two servers:
Server A has: www.masterclub.es, es.octopon.me, ...
Server B has: www.masterclub.co.il, octopon.me, ...
I issued an SSL certificate with let's encrypt, that contains all of the domain names, and bound it to all the sites.
Some time before this trouble, I used the certificate only on Server B, and there were no complaints. So my suspicion is regarding the use of the same SSL certificate, on two different servers (and IP's), whose reverse DNS records are different as well.
Please advise on the correct strategy of deploying ssl certificate(s) - should I issue one per server, or one per each domain, or one for all is enough, or is it something else?
Thanks.
Let's encrypt changed from X1 to X3. The server kept the old certificate, and that what was causing the privacy errors.
Here is are the details and how to fix:
https://community.letsencrypt.org/t/what-is-the-correct-ssl-certificates-configuration-for-multiple-domain-sub-domains-servers/23781
Related
So, I have a wildcard SSL cert from Go Daddy, and it has been installed on a few servers. However, on one particular server I cannot seem to get this thing done. Here's the process that has worked on all servers but this one:
1. Create CSR
2. Having gotten the certificate from the provider, I open the MMC certificates snap-in and import the intermediate cert to the intermediate authority store (or personal store, both have been tried). This is successful, in that I can view the certificate from the MMC
3. Go to the IIS server and under Server Certificates, I complete the CSR, point to the provided certificate and it imports into the web server successfully.
4. I go to an individual web site to assign the certificate to the web site under binding. When I select https and the IP address, the drop-down menu activates, but the certificate I just installed is not available for choosing.
5. I go back to the server Certificates, and the cert I just viewed is no longer there.
Go Daddy says to rekey, however, this makes no sense, since immediately prior to this, I installed that same wildcard cert to a different server, and it works fine. Obviously, this is something with IIS or Windows on this particular server.
Does anyone have any idea how to fix this without rekeying? Server platform is Windows 2008R2, IIS 7.5
If you have followed steps described in https://www.godaddy.com/help/iis-7-install-a-certificate-4801 then from your side it's done. And for more references, you can also check out this https://stackoverflow.com/a/43247419/7738413
Otherwise, rekeying is the last option.
I have godaddy ssl certificate for domain.There wasn't any problems with my SSL certificate and visiting my domain(Haven't receive any errors), but couple times(two weeks ago) when I visited site from other(mobile, tablet and desktop) devices(different internet) I received SSL warning. I tested my domain on sslshopper.com and in this system shows that everything is okay with our SSL(Expiry date in 200 days). But I tested my SSL in ssllabs.com and SSL got only C grade. Maybe you have any idea why such stuff happening? Is it possible that if we would change SSL to other one, there wouldn't be such error at all? Maybe you experienced something similar and you can help out. Because warning appears only sometimes and in different devices, but other than that everything is perfect
When some client devices show problems, and others don't, it must likely because some client's don't contain the necessary Intermediate or Root Certificate Authorities to establish a chain of trust.
This is not the fault of the client device.
Rather, it is up to the server-side (ie. the side sending its certificate) to supply enough of the chain (ie. its certificate, and its CA certificate(s)) so that the client can use those to fill in the steps in the chain until it gets to a certificate that is signed by another certificate that it has in its trusted CA keystore.
You're very likely only supplying the server certificate.
Also possible, but generally less likely, is that the certificates are being offered by the server in the incorrect order.
To help you further, we would need to have some details as to what software is implementing the SSL server end-point.
Cheers,
Cameron
For some of my site visitors, the SSL certificate is failing. Whatever tests I do on various browsers for me the SSL certificate is valid.
I can't think of how to test this on client side, and to identify the problem.
How would you do this?
One client gets: fatal certificate unknown
While RouMao's answer is mostly correct, he has missed what is (IME) the most common problem with SSL certificates - the certificate you are using requires an interim certificate from the CA which you have not included in your certificate chain. Most CAs provide an online tool for analysing the certificate - try the one located here.
Also, is there any correlation with which browser being used? Notably, Chrome does not handle SSL v2 by default
Most of the failing of SSL certificates were caused by visitors themselves. Somehow could not tests or verified by server implementation.
Here are some obvious examples:
Your cert is validated since April 1st 2012, but the client's local machine time is set to 2010 -- one year later than current time. In this case, the visitor should encounter problem all the times, until his machine time is later than April 1st 2012.
visitor is behind a restricted firewall. The firewall could terminate the SSL/TLS connection and re-crypt the link with a pseudo/self-sign certificate. Indeed this could be considered as a man-in-middle attach.
The Trusted Root Certification was removed by client himself
it is very hard to fix all these problem. Sometimes, you need to create a client side native application to detect or fix all the possible problems, and require client browser to execute the application each time before it enter the HTTPS mode.
P.S. most of the e-bank application do like this.
Here is my scenario:
default website on IIS 6.0 is already protected by an SSL cert with common names covering the following:
domainname.com
www.domainname.com
I have a new website on the same IIS server and need to protect it with an SSL cert with the following common name:
subdomainname.domainname.com (same domainname as default)
I do not have the freedom to add a new IP address to the server. Not an infrastructure friendly request for whatever reasons.
We also have our Exchange webmail protected by another cert on another server with:
webmail.domainname.com
I do not believe I can use a wildcard cert because exchange is on a different server, correct?
Whether I can or not use a wildcard server, how can I protect the new subdomain on the main IIS server with a new cert? Do I replace the cert on the default with the new common name representing the subdomain web site and the default web site common names. Can I assign the same cert on the same server with all common names needing protection to multiple websites on IIS 6.0?
Thanks for any help in getting this resolved.
You are correct, you would need multiple signed certificates for your servers. Godaddy offers certs for single-servers only, AFAICT. DigiCert offers multi-domain, multi-server certificates. I've never used them, so I can't vouch for anything they offer, but it shows that what you want IS available in the marketplace.
You can get a single cert and use it on multiple servers so long as the DNS entries map out to the correct servers.
Go Daddy offers several cert types and they don't make it clear how to deal with this issue.
Standard (Turbo) SSL 1 domain ~$30
Standard Multiple Domain (UCC) SSL Up to 5 Domains ~$90
Standard (Turbo) Wildcard SSL ~$200
Get the 5 domain cert with
domainname.com
www.domainname.com
subdomainname.domainname.com
webmail.domainname.com
all listed on the one cert. Complete the request on the server you started the request from then use the tools built into the windows servers to copy the cert from one server to another. Doing so doesn't remove it from the first server and adds it to the second.
I did this not too long ago. My Web server is 2008 and the mail server is 2003. In that combination I had to export as a .pfx file and then import the .pfx. If you do it from 2003 to 2003 you may be able to use the copy from another server option and save manually moving the exported file around.
In my case the cert mentions "Certificate Subject Alt Name" with
Not Critical
DNS Name: www.adomain.com
DNS Name: adomain.com
DNS Name: www.adomain.com
DNS Name: mail.adomain.com
Looks like one of those lines is a duplicate but hey it works. I don't know why the cert uses the terminology of "Not Critical" to head that section.
IIS won't let you put two sites on the same IP/port combo but it will let you put the same SSL on two different sites. The secondary site will have to use something other than 443 if you don't have the option of using a different IP address.
I've got an ssl certificate for what I think is my domain and I want to apply it to two separate applications in that domain that run under ASP classic in IIS on Windows 2000.
I have the following stupid questions:
Are certificates issued for URLs or domains? Or subdomains?
Can I use the same cert for multiple websites (applications) within that domain, or do I need a separate one?
Can I inspect the cert file to determine for what or to whom it's issued?
Thanks!
1) Web certs are issued to a domain. Specifically the CN attribute of the certificate must match the domain used to access your site.
2) Certs are usually install per host (or virtual host). If you had cert for the domain wwwapps.domain.tld you could have one app at /calendar, and one app at /contacts.
3) Yes, depending on the format and where it is, this can be easy or hard. If you have a crt file and you are running under windows, just click on it. You should see the details.
If you want to inspect a certificate that is installed on a site, you usually have to click on the padalock icon.
On windows you can also open up the MMC, add the certificate snapin and see any/all installed certificates on the local machine, or your profile.
They are issued for domains. Subdomains require their own certs. You can buy a special wildcard cert for your domain that lets you create certs for your subdomains, but they are more expensive.
If you buy a cert for mydomain.com, you can use it for anything that starts with https://mydomain.com/
Yes. You can do this for any certs. check out the lock icon in your browser's address bar.
It's usually issued to a single web server host (basically a computer cname or a record) like foo.bar.com where foo is one name for the host which the certificate request was generated for and bar.com is its domain.
Thus it will work for any application or virtual directory that responds to https://foo.bar.com - like https://foo.bar.com/planner/ - but nothing more.
For https://*.bar.com you can get a wildcard certificate that lets you handle any number of hosts without any hassel - at a greater cost.
There are also multiple-SAN (UCC) certificates that can contain a specific number of host names in a single certificate like webmail.bar.com and autodiscover.bar.com for an Exchange 2007 server serving both web access and Outlook Anywhere from the same physical machine and NIC.
If it's in .cer format simply opening it in Windows will show the details, if it's a pfx or in some other transport format you'd need to import it.
You basically install the certificate on a Web Site node in IIS and anything you can fit beneath that (or modify using a modern firewall in front of it to still respond to the issued common name foo.bar.com) will work.
Thanks! I enabled port 443 for the site at the domain on the cert, loaded the cert via directory security in IIS for each subfolder, and enabled 128-bit encryption. Worked like a champ!