1

I have a client that generates a csr, sends it to a server, the server then sign it and return the certificate as a String. the String is then decoded to a x509Certificate (using Bouncycastle's PEMParser) which is then imported to the client keystore.

The questions are:

  1. Should i verify/validate anything before importing the given client certificate? Either as a String (encoding? pre/postfix?) or as a certificate? I guess i can check that the certificate really originated from my csr (from my public key). I'm not sure i can validate that the signing authority is trusted by me (I think it's not necessarily the case if a different CA is used for signing the client's certificates and it's not necessarily trusted by the clients).

  2. What risk am i introducing by not verifying/validating anything on it? I can't think of any attack.

Thanks!

|improve this question
2

Technically your certificate is not for you. You have a certificate so you can show it to other people; it is meant to convince them, not you. You don't necessarily trust your own certificate.

As a safeguard against bugs, you may want to check that the public key in the certificate matches your private key: if the CA fumbled (badly) and sent you the wrong certificate, then you want to know it early so that you may complain and start the procedure again. Similarly, CA often send certificates back with a chain, i.e. all intermediate CA which are normally used to validate the certificate. Since a very common format for that is PKCS#7, in which the certificate are unordered, your code must make sure that it imports the right certificate in the bunch.

Attacker's power in such a process is that of nuisance: depending on the communication channels between you and the CA, he might replace your certificate with junk bytes, or another certificate with a different name or public key. Such a certificate would not be valid, and lead to simply things not working. Generally speaking, you want to diagnose such occurrences early.

|improve this answer
  • Thanks! What about Input validation? do you think there is value in testing stuff like length/characters/encoding/prefix/postfix of the PEM String before doing anything? (and if so, what would you suggest?) – yair Jul 14 '14 at 14:17
  • 1
    A certificate has a lot of internal structure (it is based on ASN.1). The decoder is supposed to check everything already. "Input validation" makes sense only to cope with cases where the decoder does not do its job. If your certificate handling library uses a poor ASN.1 decoder, well... you should switch to a better library. If the library is decent, then the only input validation which makes sense is a test on total size, to avoid denial-of-services. You can require a certificate to fit in, say, less than 30000 characters, and you will be fine. – Thomas Pornin Jul 14 '14 at 15:33

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.