SSL: Understanding self-signed-certificates

3
votes

I wondering how self-signed certificates generally getting checked in a SSL connection establishment.

Let's have a look on the self-signed certificates:

  • client and server providing a self-signed certificate with its private key (created with OpenSSL e.g.)

  • when the server receiving the "ClientHello" message from the client, he is transmitting his certificate to the client.

  • The ServerHelloDone message is sent to the client, then the client needs to verify the certificate.

When the client is receiving the server certificate, what are his steps to verify this certificate? I know that self-signed certificates generally shouldn't be used in fact that there is no third-party instance (CA) to check against.

Does the client just accepting the server certificate without any further steps or does the client already provide a server "root" certificate before the connection getting established?

1
sslopensslcertificatex509
Your last sub-question doesn't really make sense in the context of a self-signed certificate (not sure what "root" you would be talking about). In addition, the CertificateVerify message is only used for client-certificate authentication, nothing to do with verifying the server cert. – Bruno
It's an idea how self-signed-certificates getting verified. When i am talking about server "root" certificate I see it as a replacment for the root certificate for the CA certificate (in a non-self-signed-certificate environment). Sorry for the mistake about the CertificateVerify message ;-) and thanks for your advice. – Leviathan
This question appears to be off-topic because it is not about programming or development. Perhaps you should ask on Super User or Information Security Stack Exchange – jww
Thanks for your reference!!! Information Security Stack Exchange seems to be the perfect place :) – Leviathan

1 Answers

4
votes

When the client is receiving the server certificate, what are his steps to verify this certificate?

client executes certificate chaining engine to verify the certificate. Important checks are:

1) certificate signature

2) certificate subject. CN attribute in Subject field (or appropriate name in Subject Alternative Name) must match entered URL. For example, you connect to www.example.com, then this name must be listed either in Subject and/or in SAN extension.

3) cert validity

4) cert revocation

5) certificate chains up to a trusted root (presented in self-signed form)

6) other checks defined in RFC5280 (including, but not limited to: enhanced key usage, policy constraints, name constraints, etc.).

in a case of self-signed certificate, certificate chain consist of a single element -- server certificate. In this case, client skips only step 4, because self-signed certificates cannot be revoked. And this self-signed certificate must be explicitly trusted by a client as a trusted root certificate, because all self-signed certificates are root certificates.