Hello Oliver
I'm running the latest version 3.24.1-0 on debian buster.
I think the DN parsing and splitting works fine.. because in the
workflow context I see the following values
csr_subject:
1.2.840.113549.1.9.8=10.20.30.40+1.2.840.113549.1.9.2=hostname.fdqn,ou=VPN
cert_subject_parts:
- 1.2.840.113549.1.9.8
10.20.30.40
- 1.2.840.113549.1.9.2
hostname.fdqn
- OU
VPN
It looks to me that the splitting works correct, but the OID mapping
doesn't work as expected.
If I extract the PKCS10/CSR request and check it with openssl on the
cli, i get the following translation:
subject:
unstructuredAddress=10.20.30.40+unstructuredName=hostname.fdqn,ou=VPN
Hope that helps. Otherwise I can give you a copy of that output
best regards
Daniel
Am 2023-03-15 22:02, schrieb Oliver Welter:
Hi Daniel,
what version are you now running? We did some changes to the
ParsePKCS10 action exactly at the part were we parse the DN to work
with DNs that have Plus and Coma characters in the DN values so that
sounds like we did overlook some cases here.
Can you check the workflow context what is inside the
"cert_subject_parts" hash? It might just be an issue that we do not
have the OID mapping in the right place and this gets not translated.
It would help if you can share an excerpt of the context and perhaps
also the PKCS10 container.
best regards
Oliver
On 15.03.23 16:47, Daniel Hoffend wrote:
Hello
I'm having trouble with requesting certificates using the scep
interface. Our cisco routers are configured to generate a CSR that
looks like this:
unstructuredName=hostname.fqdn+unstructuredAddress=10.20.30.40,OU=VPN
This was working fine for quite some time and I've contributed some
patchs to openxpki to make those attributes works. Now we're facing a
problem that the scep server doesn't correctly translates those oids
back to readable names.
Our Enroll Profile Subject is set to:
subject:
dn: unstructuredName=[% UNSTRUCTUREDNAME.0
%]+unstructuredAddress=[% UNSTRUCTUREDADDRESS.0 %],OU=VPN
In the workflow context I see that the request has failed due to an
invalid subject
unstructuredName=+unstructuredAddress=,OU=VPN
While the csr_subject correctly states
1.2.840.......=hostname.fqdn+1.2.840......=10.20.30.40,OU=VPN
To make things more confusing. If we do an manual enrollment on the
router, upload the correct/same CSR file via WebUI everything gets
parsed and build correctly. So there must be something strange
happeing the the SCEP Request parser.
btw. I had the issue with the LibSCEP backend. Then I switch to the
newer 3.18+ SCEP Server backend, but issue is still present (invalid
subject with every scep request).
Maybe somebody has an idea.
-- Best regards
Daniel Hoffend
_______________________________________________
OpenXPKI-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openxpki-users
_______________________________________________
OpenXPKI-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openxpki-users