When renewing a certificate with a new private key, what happens with browsers that connected previously? Will the old certificate be cached and requests encrypted incorrectly? Is it possible at all to run multiple servers load balanced at layer 4 with some of them having new and others old certificates without causing connections to fail assuming no sticky sessions are used?
Clients usually do not cache SSL/TLS certificates. Only if you use the "Public Key Pinning Extension for HTTP (HPKP)" client do cache and check the provided certificate (or to be exact certain properties of that certificate). For changing the certificate HPKP can "allow" multiple certificates (e.g. one old and one new).
Regarding the load balancer: If they work on osi layer 4 I assume they work on TCP level. Therefore each server behind the balancer establishes it's own SSL/TLS session. If the sessions are not shared among the servers there should not be a problem event if not all servers use the same certificate - as long as all certificates are valid.
Clients can provide an SSL/TLS session id when starting the SSL/TLS connection, but the server decides if the session is known or not. Therefore if the client references a session from a different server nothing bad happens, client and server just establish a new session.
Related
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.
Is is possible to configure HAProxy to only allow single connection per client certificate (based on CN or other attribute)?
Each client should be able to connect even if it has already open connections, though, after successful authentication any previous connection for that certificate should be dropped immediately.
I do not think ACL's would work for this purpose.
Thanks in advance
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.
I'm trying to find out more information on the details of two-way SSL authentication. What I want to know is what verifications are done when one client receives another's certificate. (See the Verify Circle in the image below)
Two way verification http://publib.boulder.ibm.com/infocenter/tivihelp/v5r1/topic/com.ibm.itim.infocenter.doc/images/imx_twowaysslcacert.gif
Does someone has a list of all of the steps? Is there a standards document I can be pointed to? Does each server implement it differently?
Mainly what I'm asking is... Does the server do a verification against the other server's hostname vs the certificates Common name (CN)?
As #user384706 says, it's entirely configurable.
The scenario you're talking about is one where a machine is both a server and a client (and is the client as far as the SSL/TLS connection is concerned).
You don't necessarily gain much more security by verifying that the connection originates from the CN (or perhaps Subject Alternative Name) of the certificate that is presented.
There are a couple of issues:
If the SSL/TLS server is meant to be used by clients that are both end-users and servers themselves, you're going to have two different rules depending on which type of client you're expecting for a particular certificate. You could have a rule base on whether the client certificate has the "server" extended key usage extension or only the client one, but this can get a bit complex (why not).
The client (which is also a server) may be coming through a proxy, depending on the network where it is, in which case the source IP address will not match what you'd expect.
Usually, client-certificate authentication relies on the fact that private keys are assumed to be kept protected. If a private key is compromised by an attacker on the server, the attacker may also have the ability to spoof the origin IP address when making the connection (or making the connection from the compromised server directly). This being said, servers tend to have private keys that are not password-protected, so it may help a little bit in case it was copied discretely.
I think some tools are so strict that they don't only verify the CN to be the FQDN of the incoming connection: they also check that it's the reverse DNS entry for the source IP address. This can cause a number of problems in practice, since some servers may have multiple CNAME entries in the DNS, in which case the CN would be legitimate, but not necessarily the primary FQDN for that IP address.
It all really depends on the overall protocol and general architecture of the system.
RFC 6125 (Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)), recently published, considers this scenario out of scope.
The closest reference I can think of is SIP.
Mainly what I'm asking is... Does the
server do a verification against the
other server's hostname vs the
certificates Common name (CN)?
This is configurable.
It is possible to configure strict checking and not accept connections from entities sending a certificate that the CN does not match the FQDN despite the fact that the certificate is considered as trusted (e.g. signed by a trusted CA).
It is possible to relax this and do not do this check and accept the certificate or delegate the decision to the user. E.g. IE shows a pop up warning saying that certificate's name does not match FQDN. Do you want to proceed anyway?
From security perspective the safest is to do strict verification
What's necessary to migrate valid SSL certificate from one server and service provider to another?
In some cases it may be simply a matter of copying the keys to and changing apache configuration on the new server.
For example:
http://www.digicert.com/ssl-support/apache-ssl-export.htm
Some certificate authorities may tie an SSL certificate to a specific server.
Essentially, you export SSL certificates from the server that they are currently installed on, move SSL certificates to the new server, and then import SSL certificates on the new server. But this only really only applies if you are sticking with the same certificate authority ("provider")... which it sounds by your question that you are not.
Keep in mind that even if you stick with the same provider, many require that you purchase a "server license" for each server that you install an SSL certificate to, even if it uses the same private key. And speaking of private keys, it is slightly less secure to copy the SSL certificate and use the same private key on a different server. If an attacker breaks into one server and gets the private key, he will be able to listen in on the connections that other servers are making.
So my advice to you since you want to switch providers is just purchase a new one all together with the new provider once you move to the new server... But maybe I'm misunderstanding your question.
First determine if the device installed with the certs are storing the private key in hardware/software. In most today's servers, they are in software *.key files (e.g. web server SSL).
To be found near the key files are the certificate and perhaps even CSR. Moving these files to another server is generally allowed (Considering the destination server will have the same hostname) and hence keeping the same CA. Most CAs have no concern to customers who does that.
But if you are just looking to switch the service provider from one to another, simply ask current CA to 'revoke' the cert. Then start with the new Cert buying process with the new CA.