0
$\begingroup$

I'm trying to generate a csr with spongyCastle in android that has to be submited to a webservice. My problem is that the webservice always complains that the CSR is not in DER or PEM format. On the other hand, if i use Openssl command line to generate it, the webservice accepts it, so i know the webservice works and the code that submits it also. So, please can some guru spot the diferences between my generated CSR by code and the one generated by OpenSSL command line, appart from the public key ?

Created by code with spongyCastle in android

-----BEGIN CERTIFICATE REQUEST----- MIICtTCCAZ8CAQAwcjELMAkGA1UEBhMCSVQxGDAWBgNVBAMMDzM1MjgxNDA5MjAw NTc3NDEQMA4GA1UEBwwHQ0FUQU5JQTETMBEGA1UECgwKU0lTT0ZUIHNybDEOMAwG A1UECAwFSVRBTFkxEjAQBgNVBAsMCU1hcmtldGluZzCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAL9zyTyT198QtXPaHvYXfT11MjQo+W9EeU5dBMotqdzl 0OY6Bm4iNAk8PRCvVAMwnGX+ztb2cHHaXPAtoYdxiLIHO26dup1x7w/2RX12CKWV kvE1pjXsgUFL/lxjco6LNi8NPk0Mne5aJv14sQ/evyr6DbINsWKVjWFew//EvBqk r0jXu4PfIrZZXUxMiioqnSvAuec+EI52ifgx3stMVhUHSFroqbkOCmc2EKH1eX+k UtYvdNtz6kkfoXtDRBfm0pg0qZOGBXqc0FhiFkD52ChDaMCz9WvMPhZbDKpmLIrc ORGhl8A7y3BCL5dhmQVa3BgPZJymqryYs8qQbz+x6EUCAwEAAaAAMAsGCSqGSIb3 DQEBCwOCAQEAi4/5RGZI9VSJcc43bA0pEsKMlQpQv8a51I/PvhEyfL8iKvMg4poA HuOzcuvin0eaShjXtCVma7NCUg6+Ccl7iZnVJpK1vtJEp8U6lpRt1VyzzpZJXex1 uJTXuWY1u52E1lj4M81x7hqUKml61/Ahy02G3szTn6JfIK3jH76/xeUui9NWqkZE 6meb7AemimgmF9kfuhuEAhSt/+l6Pas1F6YcM54NexPNdGZ+x6l06WiVoh2TlenE aHABmk32U4BMnAYWsdq1MxpvnEriyf9Z8sYM2Zyf0C9O8Bzz9qnS8ZGMsODbTSas lEdA+M8UmQ646BB0LO4Vr7RETRX/fEl49w== -----END CERTIFICATE REQUEST-----

and the one created by OpenSSL command line

-----BEGIN CERTIFICATE REQUEST----- MIICtTCCAZ0CAQAwcDELMAkGA1UEBhMCSVQxDjAMBgNVBAgMBUlUQUxZMREwDwYDVQQHDAhDQVRBTElOQTETMBEGA1UECgwKSW5mb3JwaXJlczERMA8GA1UECwwIc29mdHdhcmUxFjAUBgNVBAMMDTEyMzQ1Njc4OTAxMjMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDJuj7e1NRGocLmAmvc95UAAGcEevG8HreSr6V2U16OTyHwIm2THZ5He6BgJwKskFLUdW1/DfLd/52b0nDymjgNRIIlJeYdEty96WRKUuacVnYegEwtyL1fTeFkajTflw0EIy/2ehNXwoDpB5mWzzWt97Cque27umP3W7a3cCz2c9f7XCx5Uq7qHFPUaaH9ys/oRpJCgw5Lfv9duV99KO4yXCfrvfmsN1y9LYKkD4MW1BUQSLvST5BDRnRAGRNFe7V3KzvnRYjH8nhv5Evm+j8n1mzrGK7DdQU6N48yKF0BPPFzhFR2ACxGUjMysHQgobPy0UToBBAxrE7qiS+oaiXLAgMBAAGgADANBgkqhkiG9w0BAQsFAAOCAQEAEQZwWzCfUaCgeccDZ47QxBv601E63qwMhFc6bteU6jKPytY7BkojvxYZwkvGJnUqg2PTxAr6YnQHY/agWZAqLE358s32f4j81Ky+aG1pmMZf5Yx+tKoDsJtxzzubdj9gukUkq/tjQRXgGVx53lM26POfsgC5/pYnECqHOKuMxTUHUrOfX0J8bSRu5BoZfr9fEsy/ha/ymmmx9jBDx8wLo7vD78MnzdXDVMONVY7KgnujnEN9xl5EdJGAfQCm+Sf0Fx9z/RUSaUYV/9s/xj4NPhqgj51EKuwg+/7oOpM3Y/x5aT+cqxHUV0J1UEi9T4kRocchi3Rn9Xn5scMN6S7A9w== -----END CERTIFICATE REQUEST-----

TIA

Nelson

Edit : I wish to thanks everyone that replied. Anyway, i've made two mistakes. The question should be more like why would the first CSR not be accepted and the second yes.

Second mistake was that it's a no problem after all. Just a stupid mistake in the code that builds the xml that missed one byte when the generated-by-hand CSR was used. Debugging 900+ chars strings is a pain.

Again, thank you all.

Improve this question
$\endgroup$
1
  • $\begingroup$ LocalityName, OrganizationalUnit and OrganizationName also differ. Also the ordering of these values is different for both which is impossible if both are "DER encoded" (which always generates the same encoded string for the same data even if unsorted sets are contained)... $\endgroup$
    – SEJPM
    Commented Oct 3, 2019 at 15:00

2 Answers 2

Reset to default
2
$\begingroup$

Assuming you posted correctly, your second file has the base64 body of the claimed PEM format as a single line, not broken/folded into lines of 64 chars (max) as required. See RFC 7468 section 2 near the end. Some software is lax about this (including, usefully, openssl asn1parse !) but not all. I wonder if you got these switched, because OpenSSL commandline (and library) always writes PEM with linebreaks as required -- although IME it may write Unix-style linebreaks (LF only) on Windows, and if you open such a file in some Windows programs like notepad it may ignore/discard the LF and treat it as one huge line while e.g. wordpad (or type or more) displays it correctly.

Improve this answer
$\endgroup$
1
  • $\begingroup$ It was the post that was wrong. (trying to make -----BEGIN / END----- look good.) $\endgroup$
    – nelson pires
    Commented Oct 4, 2019 at 9:03
0
$\begingroup$

So first, we need to decode these two CSRs which are ASN.1 encoded.

As you can see they differ in their values for the public key, for the Locality Name (= the town), the OrganizationalUnit name (marketing vs software), the OrganizationName (Inforpires vs SISOFT srl) and in the signature at the end.

However the most important issue is that they have different ordering for the attributes which differs and to my understanding this is against the DER rules which would explain the error.

Improve this answer
$\endgroup$
2
  • $\begingroup$ X.500 DN is SEQUENCE OF RDN where RDN is technically SET OF AttributeTypeAndValue (formerly AttributeValueAssertion) but in practice the SETs are always singletons so their (DER) order doesn't matter; DER does NOT change order of SEQUENCEs. It is conventional to order from 'largest' to 'smallest' -- country, stateprov, locality, org, orgunit -- but this is not specified in the ASN.1 or enforced in DER. $\endgroup$
    – dave_thompson_085
    Commented Oct 4, 2019 at 1:51
  • $\begingroup$ @dave_thompson_085 You are right. Order doesn't matter. Anyhow, it's a no problem after all. Just a stupid mistake in the code that builds the xml that missed one byte when the generated-by-hand CSR was used. Debugging 900+ chars strings is a pain. $\endgroup$
    – nelson pires
    Commented Oct 4, 2019 at 8:58

Your Answer

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

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