100

I am setting up a web service through which my company will talk to a number of business customers' services. We will be exchanging information using SOAP. I would like to handle authentication with SSL certificates provided by both parties, but I'm a bit lost on whether there's a fundamental difference between the types of certificates.

When people talk about HTTPS, they talk about getting an SSL certificate from Verisign or another authority. When they talk about client-side authentication, they talk about getting an X.509 certificate. Are these two words for the same thing, can one be turned into the other, or is some other difference that I'm not grasping?

user2428118
  • 2,788
  • 16
  • 23
Brandon Yarbrough
  • 1,103
  • 2
  • 8
  • 7

4 Answers4

68

An X509 Certificate is a type of public key in a public/private key pair. These key pairs can be used for different things, like encryption via SSL, or for identification. SSL Certificates are a type of X509 certificate. SSL works by encrypting traffic as well as verifying the party (Verisign trusts this website to be who they say they are, therefore you probably could too). Verisign acts as a Certificate Authority (CA). The CA is trusted in that everything that it says should be taken as truth (Running a CA requires major security considerations). Therefore if a CA gives you a certificate saying that it trusts that you are really you, you have a user certificate/client certificate.

Some of these types of certificates can be used across the board, but others can only be used for certain activities.

If you open a certificate in Windows (browse to something over SSL in IE and look at the certificate properties) or run certmgr.msc and view a certificate, look at the Details tab > Key Usage. That will dictate what the certificate is allowed to do/be used for.

For SOAP, the certificate can be used for two things: identification and encryption. Well, three if you include message signatures (message hashing).

Client certificates identify the calling client or user. When the application makes a SOAP request, it hands the certificate to the web service to tell it who is making the request.

Steve
  • 15,215
  • 3
  • 38
  • 66
  • Ah, neat, so all SSL certs are x509 certs, which means that I can just grab an SSL cert from Verisign and use it for client requests. An X509 cert doesn't necessarily have usage set to allow for identity or authentication, though. Cool, thanks! – Brandon Yarbrough Jan 03 '11 at 19:01
  • 4
    @CaptainAwesomePants, you may be able to use the SSL cert from Verisign as a client cert. If the key usage doesn't include Client Authentication, then it probably won't be accepted for client authentication. – Zoredache Jan 03 '11 at 21:59
  • 4
    Nice answer. But your intro is a confusing misstatement: "An X509 Certificate is a type of public/private key pair." If the private key was in there, you couldn't publish it.... Could you fix that? – nealmcb Apr 22 '11 at 21:05
  • @nealmcb updated. You are correct, however in the .NET dev world, an X509Certificate can contain the private key as well. I think thats why I wrote what I did. – Steve May 11 '11 at 15:52
  • 1
    @CaptainAwesomePants actually, not all SSL/TLS certificates are X.509 certificates. You could use OpenPGP certificates (see RFC 5081 http://tools.ietf.org/html/rfc5081 ), but it's quite rare (few stacks support them as far as I know). – Bruno May 13 '11 at 19:52
40

In TLS, the server is required to have a private key and a certificate (sometimes known as a server cert). The server cert identifies and authenticates the server. The client may optionally have its own private key and certificate as well (usually called a client cert). If a client cert is used, it identifies and authenticates the client.

On the web, with HTTPS, usually the server has a server cert but client certs are not used. This means that the client can authenticate what server it is talking to, but the server cannot authenticate what client is connecting to it.

However, in many programmatic contexts, you will typically want both endpoints to authenticate each other. Therefore, you will want to use both server certs and client certs.

In TLS, all certificates are X.509 certificates. X.509 is just the format of the data.

Certificates include a public key and a signature from a certificate authority (CA). On the web, typically web sites have a server cert that is issued (signed) by Verisign or some other well-known CA. Web browsers come with a list of almost 100 different CAs, pre-installed, and most widely used web sites have a server cert that is issued by one of those CAs. For instance, Verisign is one of the CAs in every browser's standard list of CAs. Verisign charges you money, if you want them to issue you a cert.

The alternative to getting your cert signed by a standard CA is that you can use a self-signed cert: a cert that is issued, not by one of the standard CAs, but by yourself (or anyone you want). This isn't terribly widely used on the web, because self-signed server certs cause browsers to pop up warning dialog boxes to the user, which most websites try to avoid. However, for programmatic uses, self-signed certs may work fine. And if you use self-signed certs, you don't have to pay Verisign money. You can find tutorials on how to use OpenSSL's command-line tools to create your own self-signed certs.

SSL is a synonym for TLS. (Technically, SSL is the name that was used with several older versions of the standard, and TLS is a new name for several more recent version of the standards. However many people use the two terms interchangeably.)

I encourage you to read the Wikipedia article on public key certificate for more useful background.

user2428118
  • 2,788
  • 16
  • 23
D.W.
  • 98,860
  • 33
  • 271
  • 588
  • 2
    (similar comment as in the other answer): strictly speaking, not all TLS certificates are X.509 certificates, and I've just noticed that RFC 5081 had been updated recently: RFC 6091 http://tools.ietf.org/html/rfc6091 – Bruno May 13 '11 at 19:56
  • For a server to support client certificate authentication, does the server also need to support server SSL? When I read tutorials on client certificate auth, they all seem to suggest that the server also needs to have an SSL certificate. – CMCDragonkai Jan 22 '14 at 11:46
  • @CMCDragonkai, yes. Client certificates are used with SSL/TLS, so the server must use SSL/TLS. For the future, please ask new questions in a separate question, not as comments underneath an existing question. – D.W. Jan 22 '14 at 14:44
16

"Normal" SSL certs typically are X.509 certs.
However, these can only be used for server authentication and encryption: One of the attributes of certs is its designated purpose, and you usually cannot use it for a different purpose.
Other than that, though, a client cert is pretty much identical to a server cert, just designated as "Client Authentication".

Functionally, you'll often find that some systems choose to accept only a subset of client certificates, e.g. those issued by their own CA.

AviD
  • 72,708
  • 22
  • 137
  • 218
4

Functionally, they are the same -- a public RSA key and identifying information that is signed by an authority. Practically, your server keys are usually setup with a common name that identifies the domain in question (*.wikimedia.org, for example). I don't believe there is anything restricting you from using a certificate, including self-generated, as long as it matches the authentication requirements of the other party.

Jeff Ferland
  • 38,170
  • 9
  • 94
  • 172