Good morning Oliver, thank you for your helpful reply. I will discuss your suggestion with our customer :-).
In my opinion, the delivery of all online certificates would be a good solution to make a rollover successful. We issue a new issuing certificate every 4 years which is valid for 8 years. This ensures that a server certificate that was issued with the "old" issuing certificate shortly before the 4-year period expires can still be validated until end of its lifetime. This means that there will always be a period during which two valid issuing certificates are required. If we only ever receive the last issuing certificate, all servers would have to renew their certificate. Our systems validate the server certificates every time communication is established and, in the case of the VPN tunnel, by rekeying every 2.5 hours, i.e. we would have to complete the rollover to the latest issuing certificate in 2.5 hours. Is there a notification mechanism in openxpki that the CA could use to inform its peripheral systems about the CA certificate exchange? With best regards, Ralf -----Ursprüngliche Nachricht----- Von: Oliver Welter <[email protected]> Gesendet: Donnerstag, 25. Juli 2024 17:42 An: [email protected] Betreff: EXT: Re: [OpenXPKI-users] sscep getca returns only the first Issuing certificate EXTERNAL SENDER This email originated from outside of voestalpine. Do not click links or open attachments unless you recognize the sender and know the content is safe. 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 _______________________________________________ OpenXPKI-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openxpki-users
