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.
Related
I have a web service which is secured through HTTPS. I also have client software which talks to this web service, using libcurl (which may be linked to OpenSSL, or linked to GnuTLS; I don't know which one, it depends on how the user installed libcurl). Because the web service is only ever accessed through the client software and never through the browser, the web service utilizes a self-signed certificate. The client software, in turn, has a copy of this self-signed certificate and explicitly checks the connection against that certificate.
Because of Heartbleed, I want to change the private key and certificate. However I want my users to experience as little service disruption as possible.
For this reason, I cannot change the key/certificate on a fixed date and time. If I do this then all users must upgrade their client software at that exact date and time. Otherwise, the upgraded client software won't work before the server change, while old versions of the client software won't work after the server change.
Ideally, I want to tell my users that I'm going to change the certificate in 1 month, and that they have 1 month time to upgrade the client software. The client software should be compatible with both the old and the new certificate. Then, after 1 month, I can issue another client software update which removes support for the old certificate.
So now we've come to my question: can I append the old certificate and the new certificate into a single .crt file? Will this cause libcurl to accept both certificates? If not, what should I do instead? Does the behavior depend on the SSL library or version?
Tests on OS X seem to indicate that appending both certificates into a single file works, but I don't know whether this is OS X-specific behavior, or whether it works everywhere. My client software has to support a wide range of Unix systems, including Linux (multiple distros) and FreeBSD.
Short answer: You can't.
Long answer:
Yes you can put multiple certificates in a single .crt file, regardless of platforms.
However HTTPS can only serve one certificate, instead of a crt file. So it's not the file that is limiting you, it's the protocol.
You could have a look at SNI https://en.wikipedia.org/wiki/Server_Name_Indication
to be able to serve another certificate based on the SNI information sent by the client at the beginning of the SSL Handshake
Alternatively, you could use a separate TCP port (or IP, or both) that will serve the new certificate.
But you say
The client software, in turn, has a copy of this self-signed certificate and explicitly checks the connection against that certificate.
This then requires you to release a version of your software for your clients to run, to at least have the copy of the new certificate you are going to use.
I guess you should better use a certificate signed by well-known CA, to decouple your server certificate from its validation chain, but that indeed means paying.
Yes a cert file should be able to hold multiple certificates. I would expect this to be broadly supported.
Someone just asked me to create an SSL certificate for a server that hasn't been created yet.
In fact, it's going to be hosted, so I won't even have a linux account to ssh into it.
Normally I would create the CSR on the server, and then send it to a registrar like Thawte.
Does this request make sense ? Is it possible to create an SSL cert without having ssh access to a server ? Or is my boss not understanding the process?
For web server running over https protocol, the important component of SSL certificate is the subject's CN field. This field is matched by browser against the DNS record to verify the web server is indeed whoever it claimed to be
You can purchase a SSL certificate without physically provisioning the server. However as part of purchase procedure the CA will perform domain ownership verification (and more rigorous vetting if you purchase OV/EV certs)
It doesn't matter where (physically) the command to generate private key and issue CSR is executed as long as the final product is installed once the server is provisioned
Furthermore, repointing the DNS record to different server doesn't require new cert to be issued. The important thing is you decide on DNS entry name.
Yes, you can create the CSR (PKCS10) on a different server than the one you install the certificate on. Just make sure you get the whole pfx back, with both the private and public key. However, it will now work if you have a HSM, as the private key will be stored in the HSM, and not be transportable.
Recently we created a server with tomcat and we also add SSL support for this little server. For SSL support, we need a certificate which issued by a third issuer like Entrust, Thawte etc.
A colleague said to me that the certificate is binding to a specific machine. That's once we got the issued certificate, then this cert can't be used in another machine.
I doubt this completely because the CSR doesn't contain any info of the machine. Is that true?
Thanks
The certificate isn't necessarily bound to a particular machine. To be able to "use a certificate" on a machine, you need two things: the certificate itself, and its private key. You should have generated the private key along with the CSR (depending on which tools you've used).
Some systems don't allow you to re-extract the private key (e.g. Windows has an option to import a private key in a way you can no longer export it, but as far as I understand, this can be bypassed if you have sufficient access rights on that machine). In cases where you're using a smart card or hardware token, the private key may be generated there in such a way that you can't extract it (in this case, moving the token to the new machine would make sense if necessary).
The other part is the certificate and its name. The host name(s) in the certificate (which is often also found in the CSR, although that's ultimately not necessary), should be the host name(s) of this machine, as seen by the clients trying to connect to it (see RFC 2818 Section 3.1 for detail on host name verification for HTTPS). As such, although the certificate itself isn't tied to a particular machine in terms of hardware, it will be tied to this host name (which allows you to change the hardware for this machine or its IP address for example).
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 have a thick client written in VB6 that connects to an Sql Server 2005 Database. I want to secure the connection by using SSL between the client and DB.
I've looked at these links for details on "how to" configure it.
http://msdn.microsoft.com/en-us/library/ms189067%28SQL.90%29.aspx
Question
If I want to buy an SSL certificate to use in this scenario, do I just buy the standard SSL certificate sold for websites? I would imagine so, but I want to make sure.
I guess SSL certificates are standard and can be utilized anywhere as long as the client and server know how to use that protocol.
But in case I do buy a standard SSL certificate, what do I mention as far as my website domain address etc? - Since I'm going to use it between thick VB6 client and SQL Server 2005, I wasn't clear how to go about this.
Is there any other (easier) way of securing the connection between a thick client and Sql Svr DB? My requirement is to only make the connection secure....it doesnt have to be SSL.
Thanks
Amit
You need to use a certificate trusted by the client. You can choose between using one of the trusted certificate authorities (VeriSign, Thawte, GlobalSign) or deploy a root of trust on your clients. The DB client validates the certificate the same way all SSL certificates are validated, by verifying the Subject against the name used by the client to connect.
Given that a normal DB deployment you know what your clients are, then it makes a lot of sense to pre-deploy the certificate used on the client and save yourself the cost of a true SSL system trusted authority signed cert.
If your DB clients are open ended and can add themselves at will, then it doesn't make sense to have them connect to the DB directly. Point is that there must be a deployment step (a Setup) that adds the new client to be trusted on the back end, and this step can also deploy your own root certificate as a new trusted root on the client, or, if the client is paranoid about adding an entire root, just the certificate used by the server as a trusted cert.