Does SSCEP support NDES with challenge password #46
Comments
|
Not sure about NDES never tested it but the challenge password should be a BMP String. |
|
This is my mscep_admin page: To complete certificate enrollment for your network device you will need the following information: The thumbprint (hash value) for the CA certificate is: E79F8AD3 73F7D8E0 F2688840 8563ACA1 The enrollment challenge password is: 00F7FC7937B5366F2231AC891472998C This password can be used multiple times and will not expire. For more information see Using Network Device Enrollment Service . I just copied "00F7FC7937B5366F2231AC891472998C". |
|
Yeah but that is not an BPM String and OpenSSL won't encode it for you. https://tools.ietf.org/html/rfc3641 |
|
Do you mean I need to encode challenge password? |
|
No Idea about NDES and its configuration. For a normal SCEP server you need to encode the password to a BMP string and then give it to openSSL to embed in the CSR. |
|
Hi rad1us, you are right. |
|
Manfonly, I just parsed your CSR with ("openssl asn1parse –text –in csr_file_name.csr"). I note you are using UTF-8 strings. I also note your openssl.conf doesn’t include a subjectAltName field. Can I suggest you modify your openssl.conf file to see if these changes address your problem of issuing a certificate?
Assuming this issues a SCEP certificate against NDES you can play with the string_mask values to determine if UTF-8 is supported? Regards |
|
@tedescn @manfonly 👍 Works without modification: openssl 1.0.1f |
|
I m trying with 1.0.2i. @tedescn any patch or modification can resolve this. |
The diagnostics showed that challenge password was not correctly encoded The output of: openssl req -in local.csr -noout –text has 'challengePassword :unable to print attribute' Thanks to the answer of tedescn in certnanny#46
|
Thank you. This helped me to fix my issue with NDES. Can someone please confirm if this change in openssl config will work with all types of SCEP servers? |
|
So I also ran into this however needing UTF-8 encoded attributes in the subject I could not set nombstr as that affects all attributes so I had to patch OpenSSL (openssl-3.0 branch): diff --git a/crypto/asn1/tbl_standard.h b/crypto/asn1/tbl_standard.h
index 3e8fe81eeb..246f145c58 100644
--- a/crypto/asn1/tbl_standard.h
+++ b/crypto/asn1/tbl_standard.h
@@ -36,7 +36,7 @@ static const ASN1_STRING_TABLE tbl_standard[] = {
{NID_pkcs9_emailAddress, 1, ub_email_address, B_ASN1_IA5STRING,
STABLE_NO_MASK},
{NID_pkcs9_unstructuredName, 1, -1, PKCS9STRING_TYPE, 0},
- {NID_pkcs9_challengePassword, 1, -1, PKCS9STRING_TYPE, 0},
+ {NID_pkcs9_challengePassword, 1, -1, B_ASN1_PRINTABLESTRING, STABLE_NO_MASK},
{NID_pkcs9_unstructuredAddress, 1, -1, DIRSTRING_TYPE, 0},
{NID_givenName, 1, ub_name, DIRSTRING_TYPE, 0},
{NID_surname, 1, ub_name, DIRSTRING_TYPE, 0}, |
OS: fedora 16
NDES: windows 2008r2
I can enroll without challenge password(EnforcePassword=0), but when I enabled this feature, I always get
"The password in the certificate request cannot be verified. It may have been used already. Obtain a new password to submit with this request."
Even when I change "UseSinglePassword" to 1, still get the same error message.
I use following code to generate csr:
openssl req -new -key %s -out %s -subj %s -config openssl.conf
This is my openssl.conf for challenge password:
[req]
prompt = no
distinguished_name = req_distinguished_name
attributes = req_attributes
req_extensions = v3_req
[req_attributes]
challengePassword=00F7FC7937B5366F2231AC891472998C
[req_distinguished_name]
C=CN
CN=sceptest.com
ST=Shanghai
[v3_req]
basicConstraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment
This is the generated certificate request file:
Certificate Request:
Data:
Version: 0 (0x0)
Subject: C=CN, CN=sceptest.com, ST=Shanghai
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:c1:48:66:3f:72:f4:46:86:5b:4e:33:a7:5f:ba:
c5:d3:78:92:9c:b7:ad:e5:05:28:6a:89:11:65:16:
8b:83:6c:70:ae:2d:0e:03:e4:70:1b:ca:4e:e9:8a:
a0:99:81:a4:1b:ee:0e:16:b2:bf:6a:87:a2:05:81:
8a:e9:86:0a:34:d2:a4:8f:55:27:65:5b:ae:35:b1:
99:78:55:d8:49:ca:5d:e4:c4:61:21:05:1f:98:fb:
c7:02:18:0e:30:dd:40:29:72:cb:7f:5d:1a:a3:6b:
6c:5e:27:a1:28:ab:e2:e8:23:f5:9d:e9:99:d2:c6:
1f:bb:40:28:9d:e4:2a:f4:31:5e:b3:35:b3:64:3d:
ff:6a:63:bf:d5:08:c0:cc:bd:cd:14:c8:f9:ab:04:
c2:ee:fe:91:0b:8f:ed:8c:29:34:46:68:66:da:d0:
40:e8:d8:ae:a7:64:0e:f8:8b:ef:e6:c1:61:bf:da:
81:7e:3a:a1:01:3e:b5:17:64:4b:94:d3:b3:93:78:
7f:49:9b:09:2c:1b:47:ab:04:2a:c2:03:31:d1:d8:
e8:ba:42:5b:ea:87:d4:b1:77:ac:5d:51:e8:a9:d0:
3c:59:dd:71:2e:4a:fb:68:cc:c8:11:8c:86:c0:d0:
00:4d:a1:b7:21:ef:3d:ed:50:b5:9f:85:1f:01:fe:
26:ff
Exponent: 65537 (0x10001)
Attributes:
challengePassword :unable to print attribute
Requested Extensions:
X509v3 Key Usage:
Digital Signature, Key Encipherment
Signature Algorithm: sha1WithRSAEncryption
13:dc:93:7c:cd:9c:35:17:fd:8d:3e:63:91:90:72:ef:87:ec:
e6:22:ec:60:66:0a:3f:fe:91:43:75:08:73:43:34:a0:cc:1a:
f0:67:82:45:29:41:be:b9:b5:b2:7d:c7:d7:c5:e1:06:49:26:
5a:40:fc:8f:c0:b8:60:7a:a2:54:8b:ce:3b:9f:78:0a:a9:d6:
39:4a:b8:11:49:a8:a9:98:88:52:58:67:bc:ad:5b:7f:a0:5a:
71:1f:c3:19:bc:c9:fd:11:87:c2:aa:09:8b:4f:b8:fb:ab:cd:
1e:da:c4:f9:9e:29:08:28:9c:29:14:7d:80:76:20:17:12:30:
91:9a:d7:5b:92:3a:25:21:d1:c0:31:4d:54:60:39:19:29:ed:
35:54:90:88:34:ce:b7:95:52:cd:2c:7b:b8:63:b9:7f:5c:34:
37:8d:38:ef:32:6c:97:b6:94:87:b4:b5:70:bd:68:8f:15:a3:
25:d7:89:a8:fd:d3:5f:97:e3:be:69:ae:3b:86:2d:53:77:cc:
82:00:09:32:12:39:f0:ad:d8:11:be:d2:9d:94:c9:2d:0c:a4:
15:80:71:d0:13:52:83:7a:e3:8c:9f:a2:d2:09:87:eb:2d:2f:
26:0b:09:d5:80:3d:9a:f6:fe:e3:3c:80:c6:dc:24:2f:37:08:
98:eb:68:ec
And I use following command to enroll:
sscep enroll -v -u http://10.75.212.202/CertSrv/mscep/mscep.dll -k private.key -r server.csr -l server.crt -c ca.pem-0 -e ca.pem-1
This is the output of the enroll:
/usr/bin/sscep: illegal size of payload
/usr/bin/sscep: starting sscep, version 0.6
/usr/bin/sscep: new transaction
/usr/bin/sscep: transaction id: D41D8CD98F00B204E9800998ECF8427E
/usr/bin/sscep: hostname: 10.75.212.202
/usr/bin/sscep: directory: CertSrv/mscep/mscep.dll
/usr/bin/sscep: port: 80
/usr/bin/sscep: Read request with transaction id: 677F6ADF3BBD1777855A30266E90E748
/usr/bin/sscep: generating selfsigned certificate
/usr/bin/sscep: SCEP_OPERATION_ENROLL
/usr/bin/sscep: sending certificate request
/usr/bin/sscep: creating inner PKCS#7
/usr/bin/sscep: inner PKCS#7 in mem BIO
/usr/bin/sscep: request data dump
-----BEGIN CERTIFICATE REQUEST-----
MIICyzCCAbMCAQAwNzELMAkGA1UEBhMCQ04xFTATBgNVBAMMDGVkZ2V0ZXN0LmNv
bTERMA8GA1UECAwIU2hhbmdoYWkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK
AoIBAQDBSGY/cvRGhltOM6dfusXTeJKct63lBShqiRFlFouDbHCuLQ4D5HAbyk7p
iqCZgaQb7g4Wsr9qh6IFgYrphgo00qSPVSdlW641sZl4VdhJyl3kxGEhBR+Y+8cC
GA4w3UApcst/XRqja2xeJ6Eoq+LoI/Wd6ZnSxh+7QCid5Cr0MV6zNbNkPf9qY7/V
CMDMvc0UyPmrBMLu/pELj+2MKTRGaGba0EDo2K6nZA74i+/mwWG/2oF+OqEBPrUX
ZEuU07OTeH9JmwksG0erBCrCAzHR2Oi6Qlvqh9Sxd6xdUeip0DxZ3XEuSvtozMgR
jIbA0ABNobch7z3tULWfhR8B/ib/AgMBAAGgTzAcBgkqhkiG9w0BCQ4xDzANMAsG
A1UdDwQEAwIFoDAvBgkqhkiG9w0BCQcxIgwgMDBGN0ZDNzkzN0I1MzY2RjIyMzFB
Qzg5MTQ3Mjk5OEMwDQYJKoZIhvcNAQEFBQADggEBABPck3zNnDUX/Y0+Y5GQcu+H
7OYi7GBmCj/+kUN1CHNDNKDMGvBngkUpQb65tbJ9x9fF4QZJJlpA/I/AuGB6olSL
zjufeAqp1jlKuBFJqKmYiFJYZ7ytW3+gWnEfwxm8yf0Rh8KqCYtPuPurzR7axPme
KQgonCkUfYB2IBcSMJGa11uSOiUh0cAxTVRgORkp7TVUkIg0zreVUs0se7hjuX9c
NDeNOO8ybJe2lIe0tXC9aI8VoyXXiaj901+X475prjuGLVN3zIIACTISOfCt2BG+
0p2UyS0MpBWAcdATUoN644yfotIJh+stLyYLCdWAPZr2/uM8gMbcJC83CJjraOw=
-----END CERTIFICATE REQUEST-----
/usr/bin/sscep: data payload size: 719 bytes
/usr/bin/sscep: successfully encrypted payload
/usr/bin/sscep: envelope size: 1175 bytes
/usr/bin/sscep: creating outer PKCS#7
/usr/bin/sscep: signature added successfully
/usr/bin/sscep: adding signed attributes
/usr/bin/sscep: adding string attribute transId
/usr/bin/sscep: adding string attribute messageType
/usr/bin/sscep: adding octet attribute senderNonce
/usr/bin/sscep: PKCS#7 data written successfully
/usr/bin/sscep: applying base64 encoding
/usr/bin/sscep: base64 encoded payload size: 3539 bytes
/usr/bin/sscep: server returned status code 200
/usr/bin/sscep: MIME header: x-pki-message
/usr/bin/sscep: valid response from server
/usr/bin/sscep: reading outer PKCS#7
/usr/bin/sscep: PKCS#7 payload size: 700 bytes
/usr/bin/sscep: PKCS#7 contains 1 bytes of enveloped data
/usr/bin/sscep: verifying signature
/usr/bin/sscep: signature ok
/usr/bin/sscep: finding signed attributes
/usr/bin/sscep: finding attribute transId
/usr/bin/sscep: allocating 32 bytes for attribute
/usr/bin/sscep: reply transaction id: 677F6ADF3BBD1777855A30266E90E748
/usr/bin/sscep: finding attribute messageType
/usr/bin/sscep: allocating 1 bytes for attribute
/usr/bin/sscep: reply message type is good
/usr/bin/sscep: finding attribute senderNonce
/usr/bin/sscep: allocating 16 bytes for attribute
/usr/bin/sscep: senderNonce in reply: F3AC0EC41E761C4785735394C91C8712
/usr/bin/sscep: finding attribute recipientNonce
/usr/bin/sscep: allocating 16 bytes for attribute
/usr/bin/sscep: recipientNonce in reply: 12C9526F8DE6DBD51B4D9FB2CA302C1B
/usr/bin/sscep: finding attribute pkiStatus
/usr/bin/sscep: allocating 1 bytes for attribute
/usr/bin/sscep: pkistatus: FAILURE
/usr/bin/sscep: finding attribute failInfo
/usr/bin/sscep: allocating 1 bytes for attribute
/usr/bin/sscep: reason: Transaction not permitted or supported
The text was updated successfully, but these errors were encountered: