CSR generated by NetHSM

Hi,

I have used the NetHSM to generate CSRs. Someone reviewing the generated CSR remarked that the DN was encoded as “an ASN.1 SET of Relative Distinguished Names (RDNs) instead of a SEQUENCE” and that this was apparently “allowed but uncommon”, and that this would result in interoperability problems with some existing code.

Is there a way to make the NetHSM express this as a SEQUENCE of SEQUENCE rather than SET of SEQUENCE?

(The workaround I am going to try is to create the CSR in my own code and sign it using the NetHSM and see if I can make that work).

I used the example CSR from the documentation (Operation - Nitrokey Documentation) to compare and ran the following openssl command on it:

openssl asn1parse -i -in sample.csr

Which produces the following output:

    0:d=0  hl=3 l= 241 cons: SEQUENCE          
    3:d=1  hl=3 l= 164 cons:  SEQUENCE          
    6:d=2  hl=2 l=   1 prim:   INTEGER           :00
    9:d=2  hl=2 l= 113 cons:   SEQUENCE          
   11:d=3  hl=2 l= 111 cons:    SET               
   13:d=4  hl=2 l=   9 cons:     SEQUENCE          
   15:d=5  hl=2 l=   3 prim:      OBJECT            :countryName
   20:d=5  hl=2 l=   2 prim:      PRINTABLESTRING   :DE
   24:d=4  hl=2 l=  13 cons:     SEQUENCE          
   26:d=5  hl=2 l=   3 prim:      OBJECT            :localityName
   31:d=5  hl=2 l=   6 prim:      UTF8STRING        :Berlin
   39:d=4  hl=2 l=  13 cons:     SEQUENCE          
   41:d=5  hl=2 l=   3 prim:      OBJECT            :stateOrProvinceName
   46:d=5  hl=2 l=   6 prim:      UTF8STRING        :Berlin
   54:d=4  hl=2 l=  15 cons:     SEQUENCE          
   56:d=5  hl=2 l=   3 prim:      OBJECT            :organizationName
   61:d=5  hl=2 l=   8 prim:      UTF8STRING        :Nitrokey
   71:d=4  hl=2 l=  19 cons:     SEQUENCE          
   73:d=5  hl=2 l=   3 prim:      OBJECT            :commonName
   78:d=5  hl=2 l=  12 prim:      UTF8STRING        :nitrokey.com
   92:d=4  hl=2 l=  30 cons:     SEQUENCE          
   94:d=5  hl=2 l=   9 prim:      OBJECT            :emailAddress
  105:d=5  hl=2 l=  17 prim:      IA5STRING         :info@nitrokey.com
  124:d=2  hl=2 l=  42 cons:   SEQUENCE          
  126:d=3  hl=2 l=   5 cons:    SEQUENCE          
  128:d=4  hl=2 l=   3 prim:     OBJECT            :ED25519
  133:d=3  hl=2 l=  33 prim:    BIT STRING        
  168:d=2  hl=2 l=   0 cons:   cont [ 0 ]        
  170:d=1  hl=2 l=   5 cons:  SEQUENCE          
  172:d=2  hl=2 l=   3 prim:   OBJECT            :ED25519
  177:d=1  hl=2 l=  65 prim:  BIT STRING

On further inspection of RFC5280 it seems the form expected by many CAs is something like this:

SEQUENCE {
    SET { SEQUENCE { countryName, "DE" } },
    SET { SEQUENCE { organizationName, "Nitrokey" } },
    SET { SEQUENCE { organizationalUnitName, "Someunit" } },
    SET { SEQUENCE { commonName, "nitrokey.com" } }
}

I added support for generating CSRs using the Go standard library to the GitHub - borud/nethsm: NetHSM Client library library. The code can be seen here here if you are curious.

2 Likes