0

For our current implementation we are using a self signed root certificate, which then is used to sign ssl certificates for our secure http connection.

My question relates to the verification logic on the client, which unfortunately, won't have access to the root certificate in trusted root certificate authority.

Is it enough to store the thumbprint of the SSL certificate on the client in a secret vault and then check for compliance in the callback function during the https handshake? Cosidering that it might be possible that someone creates their own SSL certificate and just uses this thumbprint value (which of course is publicly available)? Am I wrong or is it that a standard x.509 certificate can't guarante me that the data hasn't been tampered with?

Wouldn't it be safer to store the public key of the root certificate and use this to check the thumbprint for yourself?

Does this justify the additional overhead for each initial request?

2

My question relates to the verification logic on the client, which unfortunately, won't have access to the root certificate in trusted root certificate authority.

In this case you cannot validate against the root CA but must trust each certificate by its own.

... might be possible that someone creates their own SSL certificate and just uses this thumbprint value (which of course is publicly available)?

The thumbprint or fingerprint of a certificate or public key is a cryptographic hash over the certificate containing the public key or the public key alone. Since the secret private key must match the public key in the certificate and an attacker has hopefully no access to this private key (wouldn't be private anymore then) it is practically impossible for an attacker to create a certificate with the same fingerprint AND have the private key for this.

Since ownership of the private key of the certificate is checked during the TLS handshake this means it is sufficient to check the servers certificate against a stored fingerprint - provided that this fingerprint was created using a secure hash like SHA-256 and not an insecure one like MD5. But of course the application could also store the full expected certificate or public key and compare it.

Does this justify the additional overhead for each initial request?

I don't think that there is any noticeable difference between comparing the fingerprint or comparing the full certificate. If there is any difference at all then comparing the full certificate is probably the fastest since there is no need to create the fingerprint from the certificate in order to compare it.

  • How is it being guaranteed that the thumbprint matches to the data on the certificate? Suppose a man in the middle delivers me his own certificate and just copies the thumb print on it? – HansMusterWhatElse Jun 29 '17 at 7:41
  • 1
    @HansMusterWhatElse: the fingerprint is not delivered by the server but it is always computed from the certificate or public key. So there is no such thing as just copies the thumb print on it. – Steffen Ullrich Jun 29 '17 at 7:50
  • Oh .. I didn't know that this thumbprint doesn't get delivered by the server and is generated by the client (it was always there on the certificate and i just assumed that it is a part of the certificate). This would actually answer my whole question. – HansMusterWhatElse Jun 29 '17 at 8:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.