7

Is there any difference between a X509 TLS client cert and a server cert?

I had been implementing certificate-based mutual authentication and hence trying to get/use certificates for IoT devices. While we are pretty clear on server certificates, I was wondering if the client certificates that individual IoT devices will load and present to the server for their authentication are same/similar to what is used for a server.

Will client certs also to be acquired from a CA and then they will be validated by a server via root CA cert in the same way as server cert is validated against the root CA?

schroeder
  • 123,438
  • 55
  • 284
  • 319
Akhilesh Gupta
  • 163
  • 9
  • I think the question is too bread in its current state. While TLS server certificate validation is more or less standardized, client certificate validation varies between different mutual TLS impplementations. It would be better if you share more details on software you use. – Crypt32 May 04 '21 at 19:19
  • I'm used to client certs being self-signed but it might be a local thing. Maybe somebody else can enlighten. Since the server is recognizing the individual cert anyway, having it chain-signed doesn't seem to add much. – Joshua May 05 '21 at 15:18
  • @Crypt32 I had been using wolfSSL on client side (IoT Device). IoT Device is emulating here in vehicle telematics control unit (TCU), which is NXP MPC5748G device. we intend to enable certificate based authentication for each device (vehicle). we are using embedded PKI acquired from a CA (Comodo). so considering that there will be a large number of vehicles each provisioned with its certificate to represent ites identity, same needs to be authenticated when it connects to the backend server (Azure IoT). – Akhilesh Gupta May 09 '21 at 09:23

3 Answers3

11

Structurally, client and server certs are the same. Both will need keyUsage: digitalSignature and will contain the same type of RSA or ECDSA key. They chain to an intermediate and root CA via Issuer and AIA fields in exactly the same way as server certs. They handle revocation via CRL or OCSP in exactly the same way as server certs.

However, depending on the enforcement / authorization rules in your server, you may need to put different metadata in the client certs. For example:

  • Server certs almost always have a SubjectAltName of type dNSName matching the public domain name at which the server can be reached. This makes absolutely no sense for a client. Often instead you see a serialNumber DN component, or one of the less common SAN types.
  • Your server may be configured to require client certs to have the extendedKeyUsage: id-kp-clientAuth.
  • Your server may enforce groups, privileges or access controls based on policy OIDs or other custom v3 extensions.

Again, these are all "may" type items and will depend on how you've built your server; though I do recommend that you think about having some kind of access control rather than blindly accept any cert from your root CA.

Mike Ounsworth
  • 57,707
  • 21
  • 150
  • 207
  • Thanks Mike! this clarifies. while initial details in your response give a good insight, I really liked your last lines of response! – Akhilesh Gupta May 09 '21 at 09:30
5

Yes, in technical terms of how the certificate are constructed and signed, client and server certificates are very similar. They're both just public key, some arbitrary metadata, and a CA signature, and they're constructed pretty much the same way. The only difference between server and client certificate is basically just what metadata is attached to the certificate and how those metadata are validated against the entity.

In theory, if you disable the certificate validation and usage constraints checking in your TLS library stack or if the certificate doesn't specify usage constraints, you can actually use either client certificates as server certificate and vice versa. The cryptography doesn't actually distinguish between client and server certificates, it's only the validations done by the applications that cares about usage constraints and if you control both the client and server, you're free to specify whatever validations you want to enforce for a particular connection.

With server certificate, the certificate metadata specifies the DNS name that the certificate is valid for in the SAN field, and the certificate is validated against the domain name of the server the the TCP stack is connecting with.

With client certificate, the certificate contains the user attributes that the CA had validated. And the server verifies these attributes against its authentication requirements. You can for example add an attribute specifying that the holder of the certificate has blue hair colour, and your server may only allow connections if the client has green hair.

Note that for both server and client certificates, you don't necessarily have to use a public root CA, but because of the way certificates are used, it's much more common for client certificate to use private root CA than with server certificates.

When you use private root, you can define your own certification practice statement (CPS) which allows you to specify your own authentication requirements and any custom attributes that are required to be included in the certificates issued by the private root. This is a level of control that you won't have with public root client CA, which usually just provides simple identification of email address against a person's name because most publiclt rooted client CA are used for email cryptography, not IoT device identification. If you give your IoT devices each their own DNS names, then you may be able to use server certificates with publicly rooted CA as a client certificate, but this would be somewhat of an unusual arrangement.

Note that some CA that sells server certificates against public root CA also provide CA service for private root management. This can be an option to use if you want a professionally managed private root CA but don't want to build your own CA infrastructure from scratch.

Lie Ryan
  • 31,089
  • 6
  • 68
  • 93
1

As an additional remark, server certificates are always machine certificates while client certificates are generaly human being certificates.

The difference is that server certificates are given to an identified member of an organization after they could prove that they belong to the organization and are entitled to manage server certificates, while client certificates are generaly given to a specific human being after they can prove their identity. A less strict version is given to the holder of a specific e-mail address and can later be used as a proof that something has be signed by that holder.

As you are speaking of IoT, your client certificates will neither identify a human being nor even an e-mail holder. That means that what matters is the way you intend to identify your devices. If they have a DNS name or a fixed IP address, the certificate could use that as the identification exactly the same as it would identify the name of a server. Said differently they would be very close to a server certificate. If you use a private name in a public domain, they it would be closer to a mail holder certificate, except that the name would not be a valid address.

Serge Ballesta
  • 25,636
  • 4
  • 42
  • 84