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).
Related
I am new to TLS/SSL so this might be a very basic question, but I've been searching a lot an could not find an answer.
I am trying to implement a TLS/SSL client. This client will run on an embedded unit with Windows OS on it (XPe or WES7). My implementation uses GnuTLS.
How do I get the list of trusted authorities to my unit so my client can verify the server's certificate? Is it supposed to be a file stored on the client side, that the client is responsible for keeping up to date? Or can my client somehow get this list from the internet each time it is needed and not maintain it locally?
The Certificating Authority (CA) master certificates are stored client side and the client is responsible for keeping them up to date. Keeping them up to date isn't as hard as it sounds, as CA certificates aren't changed that often - most are valid for 5-10 years at least.
Client side storage is necessary because any given internet site your application uses might be compromised.
To get a list, you might start by looking at the CA certificates distributed with a browser or at the cacerts file distributed with Java. Before releasing your code, you'll probably want to check that the certs you use are genuine by checking them against information provided by the CA.
Go to any Windows machine and run "certman.msc" from command-line. Export each CA certificate (Intermediate Certificates, Trusted Authorities) to file (BER, PEM), then import these certificates into your embedded software. Now you can validate email certificates, the same way Windows does (i.e. using various x.509 related RFCs and CRLs)
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.
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.