2
$\begingroup$

I'm generating certificate signing request in iOS, which does not provide proper ready-made API for CSR generation. Now the library I have used for CSR generation produces the different signature for CSR compared to openssl with the same private key.

How is the signature generated and do you think there is an error somewhere, if the signature generated by openssl and the library I'm using does not match?

$\endgroup$
1

1 Answer 1

1
$\begingroup$

The signature over PKCS#10 is defined in RFC 2986, specifically section 4.2 (on page 7).

The signature process consists of two steps:

  1. The value of the certificationRequestInfo component is DER encoded, yielding an octet string.
  1. The result of step 1 is signed with the certification request subject's private key under the specified signature algorithm, yielding a bit string, the signature.

The signature is over all the significant information in the request and includes all the DER-encoded attributes in the PKCS#10 signing request.

If there are any missing or additional attributes in the PKCS#10 certificate request, or if any of the attributes differ by even one single bit, then the signature will be completely different. This could include using a different string encoding (printable ASCII string vs UTF-8), but also different dates etc.

If you want to find the difference, you can decode your certificate request here. You might have to strip your request in PEM format or convert your request in DER format to base 64 before using this tool. You could also use openssl asn1parse functionality for this.

Finally, it could also be that a different signing algorithm is used, e.g. PKCS#1 v1.5 padding vs PSS padding. They would both generate the same amount of bytes. PSS is non-deterministic (uses a random bytes) by the way; if it is used the signature would be different each time regardless of the input. Normally PKCS#1 v1.5 padding is still used though.


As Dave mentions, the best way to validate the correctness of a signature is not to compare it but by verifying the signature and validating the attributes, possibly by using other software. That way non-significant changes won't play a role within the validation.

$\endgroup$
2
  • 1
    $\begingroup$ You can also use openssl req -in file -verify [-noout] to check the self-signature. (Although I'm not sure it handles padding other than PKCS1v1_5; 1.1.0 uses EVP_DigestVerify* which could handle this but I don't see it being set, and earlier doesn't even do that.) $\endgroup$ Oct 20, 2016 at 4:30
  • $\begingroup$ Yeah I guess fringe protocols such as this don't get updated as often. Probably best to stick to PKCS#1 v1.5 signatures for now. $\endgroup$
    – Maarten Bodewes
    Oct 20, 2016 at 9:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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