# CSR generated by NetHSM
**URL:** https://support.nitrokey.com/t/csr-generated-by-nethsm/6873
**Category:** NetHSM
**Created:** [March 6, 2025, 4:15pm UTC](https://support.nitrokey.com/t/csr-generated-by-nethsm/6873 "2025-03-06T16:15:21Z")
**Posts on this page:** 4
**Page:** 1
### Author:  [@borud](https://support.nitrokey.com/u/borud)
#### Post date: [March 6, 2025, 4:15pm UTC](https://support.nitrokey.com/t/csr-generated-by-nethsm/6873/1 "2025-03-06T16:15:21Z")
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](https://docs.nitrokey.com/nethsm/operation#key-certificate-signing-requests)) to compare and ran the following openssl command on it:
openssl asn1parse -i -in sample.csr
Which produces the following output:
```auto
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
```
---
### Author:  [@borud](https://support.nitrokey.com/u/borud)
#### Post date: [March 6, 2025, 6:31pm UTC](https://support.nitrokey.com/t/csr-generated-by-nethsm/6873/2 "2025-03-06T18:31:53Z")
On further inspection of RFC5280 it seems the form expected by many CAs is something like this:
```plaintext
SEQUENCE {
SET { SEQUENCE { countryName, "DE" } },
SET { SEQUENCE { organizationName, "Nitrokey" } },
SET { SEQUENCE { organizationalUnitName, "Someunit" } },
SET { SEQUENCE { commonName, "nitrokey.com" } }
}
```
---
### Author:  [@borud](https://support.nitrokey.com/u/borud)
#### Post date: [March 7, 2025, 3:10pm UTC](https://support.nitrokey.com/t/csr-generated-by-nethsm/6873/3 "2025-03-07T15:10:14Z")
I added support for generating CSRs using the Go standard library to the [GitHub - borud/nethsm: NetHSM Client library](https://github.com/borud/nethsm) library. The code can be seen here [here](https://github.com/borud/nethsm/blob/717ab20caa854f45833b7142495256f5f9ba791b/session_keys.go#L137) if you are curious.
---
### Author:  [@ansiwen](https://support.nitrokey.com/u/ansiwen)
#### Post date: [April 30, 2025, 3:15am UTC](https://support.nitrokey.com/t/csr-generated-by-nethsm/6873/4 "2025-04-30T03:15:52Z")
This will be fixed in the next release. See: [keyfender: use RDN singletons in CSRs · Nitrokey/nethsm@f3349ea · GitHub](https://github.com/Nitrokey/nethsm/commit/f3349ea095af33bf29daa9b92de5d8757134a4da)