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.
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.
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.
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.
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.