We have a website with SSL configured. 2 days back SSL certificate was expired so I purchased a new instead of renewing. I have configured the new one. Now some of users are still getting SSL certificate expired issue although the new one is configured.
I want to force the browser to recheck the new SSL certificate using some server side configuration since we can not go and update each user browser certificate manually. It have to be done using some server side configuration. We are using Nginx.
This is really critical to us.
Please help in this regard.
Thanks!
The certificate is validated by the client only when the server sends one. The server sends one with each full TLS handshake. The browser does not somehow cache an old certificate and ignore the one sent by the server when validating.
It is more likely that you've not fully rolled out the new certificate on the server side. For example if you have multiple servers make sure that all have the new certificate. If your server provides access for IPv4 and IPv6 make sure that in both cases the proper certificate is served. If you provide service on multiple ports make sure that they all use the new certificate.
It's also possible your affected users are behind a proxy that caches certificates. For example if they're behind a Smoothwall proxy that generates its own certificates after inspecting HTTPS traffic and caches them.
Either way, if you've updated the certificates on your server and restarted the necessary services, it's probably nothing you have control over and will most likely resolve itself in time.
Related
I am using the Let's Encrypt IIS client from https://github.com/Lone-Coder/letsencrypt-win-simple to generate a certificate for a server. Since the certificate is only valid for three months, I want it to auto-renew.
But the server for which I need that auto-renewing certificate is only bound to https:||mysubdomain.mydomain.com:443 and smtp:||mysubdomain.mydomain.com:25.
Both http:||mysubdomain.mydomain.com:80 and ftp:||mysubdomain.mydomain.com:21 point to a different server.
As you may have guessed, the error that is now thrown during the process is "The ACME server was probably unable to reach http:||mysubdomain.mydomain.com:80/.well-known/acme-challenge/abcdefgh...xyz".
It is completely clear to me why, but I can't fix it, because http:||mysubdomain.mydomain.com has to point to the other server. If the ACME server would try https:||mysubdomain.mydomain.com:443/.well-known/acme-challenge/abcdefgh...xyz, but ignore any certificate issue, he would successfully find the challenge.
Is there anything I can do, any feature I have overlooked, that would help me to get automated renewal working?
There are multiple options:
http-01
Redirect http://example.com/.well-known/acme-challenge/* to https://example.com/.well-known/acme-challenge/*, Boulder will happily follow any such redirect and ignore the provided certificate. That's the most simple way if you have access to the other server and can configure that redirect. It's a permanent redirect that you don't have to adjust, it'll be just fine every three months.
The option to use HTTPS directly has been removed due to security issues with some popular server software that uses the first host defined if some other virtual host doesn't define any HTTP host, which might lead to wrong issuances in multi-user environments aka shared hosting.
tls-sni-01
If you want to use just port 443, you can use another challenge type called tls-sni-01. But I think there's no client for Windows available yet that supports that challenge type.
dns-01
If you have control over the DNS via a simple API, you could also use the DNS challenge, it's completely independent of the port you can use.
I have SSL working fine in production but have some issues locally.
When I run the site it opens 2 tabs, one http:// and one https://
I want to just use the http:// tab locally for testing. When I go to a page that requires https I get the error:
Unable to make a secure connection to the server. This may be a
problem with the server or it may be requiring a client authentication
certificate that you don't have
I have added the certificate to:
Persona/Certificates
Trusted Root Certification Authorities/Certificates
Intermediate Certification Authorities/Certificates
Everything works fine locally when I use the https:// tab.
Do I need to add the certificate somewhere else too?
Using SSL certs locally is always a challenge. When the website opens, it's likely using the loopback IP (127.0.0.1) which will always (rare exceptions, perhaps, that I can't think of) give a certificate error, because the cert is bound to a domain name, not an IP. Ideally you'd probably want to not use your websites real SSL cert locally anyway for security reasons.
You can use a self signed cert for localhost, which should work:
http://social.msdn.microsoft.com/Forums/en-US/wcf/thread/32bc5a61-1f7b-4545-a514-a11652f11200
Also, I just blogged a code snippet we've used before -- in short, it just avoids using SSL for local connections and otherwise lets you define which pages/folders should otherwise be SSL protected...
http://www.structuretoobig.com/post/2013/02/19/Skipping-SSL-Connections-Locally.aspx
I'm using SSL certificates in a client-server application; both the client and the server are using 2 certificates that will expire soon. Normally, you'd just replace the certificates with new ones, but this cannot happen at once because of the huge numbers of clients.
So, if only the servers and a part of the clients are updated, the rest of the clients won't be able to authenticate anymore.
A quick fix is to replace the binaries with a version which simply disregards expiry date of the certificates; the update of the clients can be done sequentially, as long as it will finish before the certificates expire.
Long term solutions I thought about:
use Puppet to push new certificates on clients
unfortunately, not viable because not all clients are/will be managed via Puppet
use a second set of certificates
if first set has expired, use the second one
in this manner, server will have new certificates, a part of clients will have new certificates and the rest of the clients will have old certificates, but everything works
client requests a new certificate from the server, if the current one has expired.
Are there any other solutions?
I assume you use the SSL certificates for an online SSL connection, like HTTPS, or SFTP.
The big question is: Do you still trust and want to use your server-side key! If so you can just re-issue the server certificate with a new expiration date still using the old key and thus extending the lifetime. The question is, if you still trust the old key or if it should be replaced. Old clients may still connect to you at that point.. You are still using the same public / private key pair, just made a new 'lifetime version' of the certificate for it. (That is what most public servers do..)
Using two sets of active SSL certificates for different keys on the server side is not really viable and only possible if you have good control over the handshake process on the client side and your server application supports it. The issue is that during an SSL negotiation, the server has to send its certificate first and the only indication it might get from the client is a ServerName extension during the ClientHello. (Assuming the client actually sends one). Otherwise the server is 'at a loss' on what the other side will or will not support. (There are some other extensions that might help for in indicating supported CA certificates, but your clients should support those).
The first is the most practical for the clients that do support it. Just renew their certificates (and perhaps keys) and push them. And you are done with those.
For the others, updating the client software and making sure they generate a new key and request a new certificate from the server when they need it (or in advance) might be the best solution.
We host many sites with domains on a single IP ie. www.domain1.com, www.domain2.com. We want to secure /admin using SSL. Historically each SSL cert needs a unique IP address. These are small sites and acquiring / assigning an individual IP to each site is unrealistic both in terms of maintainability and cost. Because we are not using sub domains the wildcard SSL cert approach won't work.
Googling around I found that Apache can do this by using TLS, see answer here:
https://serverfault.com/questions/109766/ssl-site-not-using-the-correct-ip-in-apache-and-ubuntu
My question is whether this is possible with IIS 7.5 too? If so, does anyone know how to set this up?
Thanks in advance
Dave
SSL and TLS basically are the same. TLS is the successor to SSL where TLS 1.0 is basically the same as SSL 3.1.
What makes the difference though is the support for SNI. This allows the browser to tell the server for which hostname the request is without the need for the server to decrypt the request.
Normally a webserver looks at the hostname header to decide for which virtual site the request is. But when SSL/TLS is used, the entire request (including all headers) are encrypted. In order to read the headers the server would have to decrypt the request but it can't do that without using the proper certificates. To know which certificate to use, it would need to know for which site the request is but it can't know that because that information is in the encrypted request. A classic chicken/egg problem. This is where SNI steps in.
SNI requires a reasonably new OS / browser / server and is not yet supported by IIS. It will be supported in Windows Server 2012 and IIS 8.0 (due for release this year).
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.