3

CentOS 5.x

The short version:

Is there a way to change the encoding format for an existing CSR "Country Code" field from UTF8 to Printable String?

The long version:

I've got a CSR generated from a product using standard java security providers (jsse/jce). Some of the information in the CSR uses UTF8 Strings (which I understand is the preferred encoding requirement as of December 31, 2003 - RF 3280).

The certificate authority I'm submitting the CSR to explicitly requires the Country Code to be specified as a PrintableString. My CSR has it listed as a UTF8 string.

I went back to the latest RFC - http://www.ietf.org/rfc/rfc5280.txt. It seems to conflict specifically on countryName. Here's where it gets a little messy...

The countryName is part of the relative DN. The relative DN is defined to be of type DirectoryString, which is defined as a choice of teletexString, printableString, universalString, utf8String, or bmpString. It also more specifically defines countryName as being either alpha (upper bound 2 bytes) or numeric (upper bound 3 bytes). Furthermore, in the appendix, it refers to the X520countryName, which is limited to be only a PrintableString of size 2.

So, it is clear why it doesn't work. It appears that the certificate authority and Sun/Java do not agree on their interpretation of the requirements for the countryName. Is there anything I can do to modify the CSR to be compatible with the CA?

3
  • @ChrisS Sorry, that was poor terminology on my part. They want the Country Code to be specified in printableString format.
    – Mike B
    Aug 29, 2012 at 20:48
  • Very late but for the record: 3280 tried to make UTF8 preferred for DirectoryString but it flopped and 5280 made that Printable or UTF8 preferred and others grandfathered. But countryName is not DirectoryString and has always (2459,3280,5280) been Printable(alpha2) only; the X.400 CountryName type which allows both alpha2 and numeric3, although the name looks similar, is NOT used for the X.509-then-X.520 countryName attribute. Oct 28, 2023 at 8:37
  • PS: no Java cryptoprovider ever handled creation of CSR, or the DN in one, although some library classes can do the latter. I don't know what the 'product' was or who was responsible for what, but keytool in Java 6u45 (the oldest I now have, from 2014) correctly uses Printable-or-UTF8. Oct 28, 2023 at 8:53

1 Answer 1

3

Figured it out. Here are the basic steps:

1) Open the original CSR and copy the base64 data between the “——-BEGIN CERTIFICATE REQUEST——-” and “——-END CERTIFICATE REQUEST——-” markers.

2) Put this data into a base64 decoder and save the output as a binary file. There are a variety of online services that can do this or if you prefer there are local tools as well.

3) Download/install a hex editor. Use it to open the decoded binary file.

4) Look for two values right before the countryName:

0C
02

5) Edit the value 0C (UTF8String) and change it to 13(Printablestring)

6) Save the changes and use a base64 encoder to encode it back to base64.

7) Add the base64 data back in between the “——-BEGIN CERTIFICATE REQUEST——-” and “——-END CERTIFICATE REQUEST——-” markers.

2
  • Welcome to Server Fault. Remember to accept your answer by clicking the outline of the check mark next to it until it turns green, so that others know your issue has been resolved. Oct 18, 2012 at 21:16
  • Of course that makes the CSR's signature invalid, and a proper CA should reject it, but apparently yours didn't Oct 28, 2023 at 8:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .