Hi Andreas,
Am 07.09.2018 um 14:08 schrieb [email protected]:
Hi Oliver,
Works like a charm now :)
glad to hear ;)
There was a little misunderstanding from myself. I though OpenXPKI will do the
auth stuff. So after adding the SSLOptions, a correct Server cert/key/chain it
went as expected :)
Well thats half the truth - the authentication step is split into two
parts. The apache handles the TLS authentication and therefore is
responsible to ensure the client has access to the private key of the
provided certificate but the validation if the certificate is from a
trusted CA is done inside OpenXPKI.
You CAN configure your apache using the SSLVerify options to exclude
unwanted TLS clients but we do not expect this, so even the
"SSLVerifyClient optional_no_ca" is fine for us.
I got one more question ;)
I have in my requests the CN and would like to add other Stuff like OU, O, L
and so on when issuing the cert.
enroll:
subject:
dn: CN=[% cn %],OU=XXX,O=XXX,L=Berlin,ST=Berlin,C=DE
When requesting over the Gui it works fine but via RPC where I don't enter the
CN (but is in the REQ) the Subject looks like:
CN=,OU=XXX,O=XXX,L=Berlin,ST=Berlin,C=DE
Short Answer: use "CN=[% CN.0 %]"
Long Answer: The CSR is parsed and stored with the DN attributes as
Arrays with attributes names all uppercased. Have a look into the
"Workflow Context", you should see the parser result in the key
cert_subject_parts there.
Oliver
--
Protect your environment - close windows and adopt a penguin!
_______________________________________________
OpenXPKI-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openxpki-users
