Hi Ralf,
the profile field shows the profile information used by the current
realm when issuing an end entity certificate, as the CAs are not
entities of the current realm this is n/a.
As the RFCs for SCEP and EST do not provide any exact information on the
content of the "cacerts" response, especially if there are multiple
valid issuers, we decided to deliver the current chain as Martin already
mentioned. I am also not a big fan of using those protocols for "chain
management" which you are likely trying to do. The (from my POV) right
way is to send complete chains alongside with the certificates and for
systems where this is not possible set up a dedicated distribution
mechanism.
But - it would not be OpenXPKI if your wish would not be possible :D As
both commands are backed by a workflow, all you need to do is to create
a new one that generates the expected answer. The easiest way would be
to prebuild the response but the existing code blocks should also
provide the required functionality to do this on the fly. If it is an
option for you to get an enterprise subscription, there is a set of
workflows and modules to handle those use cases.
best regards
Oliver
On 25.07.24 16:55, Bernhard Ralf via OpenXPKI-users wrote:
If I am looking for the certificate information at the openxpki-WebGUI, the field
"Profile" shows for all of them: n/a (certificate is not an end entity)
Perhaps this is important?
With best regards,
Ralf
-----Ursprüngliche Nachricht-----
Von: Bernhard Ralf
Gesendet: Donnerstag, 25. Juli 2024 16:44
An: [email protected]
Betreff: Re: [OpenXPKI-users] sscep getca returns only the first Issuing
certificate
Hi Martin, many thanks for your fast reply.
Yes, I would like to test a CA rollover.
Yes, I see in "Tokens of type: certsign" three token aliases with token status
"ONLINE" (from 23.12.2023, 15.07.2024 and 18.07.2024). openxpkiadm alias shows them, too.
"If this is the case, the easiest way to test if the CA rollover worked is to simply
issue a CRL and force CRL creation. That should result in CRLs created for all currently
valid Issuing CAs, including the newly imported one."
Yes, this works. Via the Web GUI I called "PKI Operation-> Publish CA/CRL".
After then the following CRLs have been generated at 23.7.24 at the webserver download
folder:
- Root_CA.crl: Contains no revocations
- Issuing_CA_2023-11.crl: Contains all revocations from 16.1.24-19.7.24
- Issuing_CA_2024-07-15: Contains all revocations from 15.7.24-19.7.24
- Issuing_CA_2024-07-18: Contains all revocations from 19.7.24
"Next you might want to test certificate issuance, e. g. via a manual certificate
request. The system will automatically determine the most recent Issuing CA capable of
issuing the requested certificate in the PKI Realm and use it to issue the
certificate."
Yes, this happens. The new certificate is coupled with the most recent Issuing
certificate.
"Also, please provide the output of openxpkiadm alias --realm REALM --filter all so
we can see how this is set up on your system."
I´m geting
=== functional token ===
vault (datasafe):
Alias : vault-1
Identifier: WWGhkCF1gUP2R509VLmA_OQSj2o
NotBefore : 2023-12-03 14:53:37
NotAfter : 2031-12-03 14:53:37
ca-signer (certsign):
Alias : ca-signer-4
Identifier: 8tZYfkmP6Bbj7f_9-Yiy1msRljI
NotBefore : 2024-07-18 12:12:15
NotAfter : 2032-07-18 12:12:15
Alias : ca-signer-3
Identifier: tiX8BcLVVnvIz6F1nqO62emX2Jo
NotBefore : 2024-07-15 10:12:16
NotAfter : 2032-07-15 10:12:16
Alias : ca-signer-1
Identifier: ukYUywMcLxPIAAqAQaxl3DN-IhI
NotBefore : 2023-12-03 15:00:24
NotAfter : 2031-12-03 15:00:24
ratoken (scep):
Alias : ratoken-1
Identifier: Zh1QHImmZzHrpPL6TMWRcF6w6SQ
NotBefore : 2023-12-03 15:07:07
NotAfter : 2027-12-03 15:07:07
ratoken (cmcra):
Alias : ratoken-1
Identifier: Zh1QHImmZzHrpPL6TMWRcF6w6SQ
NotBefore : 2023-12-03 15:07:07
NotAfter : 2027-12-03 15:07:07
=== root ca ===
current root ca:
Alias : root-1
Identifier: dsdt4ZI412g9vekuH2j6UhxlCtU
NotBefore : 2023-12-03 14:54:18
NotAfter : 2039-12-03 14:54:18
upcoming root ca:
not set
Now we are coming to the strange behavior.
--->
"Apart from this, the enrollment interfaces can be asked to return the CA
certificates required to complete the certificate chain for a requested certificate of
the end entity. For SCEP this is the GetCACert command. It will by default return the CA
certificate chain that would complete a newly issued end entity certificate."
1. Getting cacerts by calling the GetCACert-command: curl -s
http://pki.dbmas/scep/generic?operation=GetCACert | openssl pkcs7 -inform DER
-print_certs
--> gives me
subject=C = DE, O = XXX, CN = SCEP RA 2023-11 issuer=C = DE, O = XXX, OU = YYY,
CN = Issuing CA 2023-11
subject=C = DE, O = XXX, OU = YYY, CN = Issuing CA 2023-11 issuer=C = DE, O =
XXX, OU = YYY, CN = Root CA 2023-11
subject=C = DE, O = XXX, OU = YYY, CN = Root CA 2023-11 issuer=C = DE, O = XXX,
OU = YY, CN = Root CA 2023-11
I would expect the Issuing certificates from 2024-07-15 and 2024-07-18 too.
2. Getting cacerts by calling EST-URL: curl -s
https://pki.dbmas/.well-known/est/cacerts | base64 -d | openssl pkcs7 -inform
DER -print_certs
--> gives me
subject=C = DE, O = XXX, OU = YYY, CN = Issuing CA 2024-07-18 issuer=C = DE, O
= XXXG, OU = YYY, CN = Root CA 2023-11
subject=C = DE, O = XXX, OU = YYY, CN = Root CA 2023-11 issuer=C = DE, O = XXX,
OU = YYY, CN = Root CA 2023-11
I would expect the Issuing certificates from 2023-11-23 and 2024-07-15 too.
The results of both should be the same.
Furthermore, I need GetCACert for getting all CA certificates to validate other
server certificates in the system environment, which in principle could have
been issued with any of the ONLINE certificates mentioned here.
Do you have any idea for this behavior?
P.S: I am using the debian package openxpki 3.26.0-0.
With best regards,
Ralf
_______________________________________________
OpenXPKI-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openxpki-users
--
Protect your environment - close windows and adopt a penguin!
_______________________________________________
OpenXPKI-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openxpki-users
