Ah okay.
I found two files that needed to be patched. I'll try to fix it, send a
pull request and let you know if my test is successful.
Naaaaa ... I think it's faster to patch the 2 perl libs instead of
changing the workflow. I'll dive into it.
regards
Daniel
Am 2023-03-18 09:07, schrieb Oliver Welter:
Hi Daniel,
I did not look into this closer but as we have changed the place where
the mapping from the bare OIDs to the verbose names has changed with
3.24 this sounds pretty much as we do not have those OIDs in the new
library.
The quick workaround would be to use the OID strings as keys in the
subject composer which you need to revert once we added the OIDs to
the library.
Oliver
On 16.03.23 09:54, Daniel Hoffend wrote:
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
_______________________________________________
OpenXPKI-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openxpki-users
