Hi, > Thanks it mostly did the trick – but still some issues. It seems token > rollover didn’t work. The crl issuance is trying to use casigner-1, but alias > with current cert is for casigner-2. > I also verified with openssl that crl issuance does work manually. > Maybe this is a novice error, but I gathered from the docs that token > rollover is automatic?
Maybe a generic description of the process will help understand what is going on. CA rollover is automatic in OpenXPKI if configured correctly. The system basically does the following for certificate issuance (rollover): - the system generates a list of all currently valid certsign tokens have been configured for the PKI Realm - the token with the highest NotBefore date is selected at runtime for certificate issuance For CRL generation, it is slightly different: the system iterates through all currently valid certsign tokens and issues CRLs for all of them. The basis for making this work is that OpenXPKI must be able to associate a given certsign token/issuing certificate with the correct private key. The certsign token is defined by declaring it via openxpkiadm and setting an internal database that identifies a particular certificate as "special". This is done by assigning an alias to that certificate, normally also a generation ID is also assigned which caters for CA generations. If not implicitly specified, the generation starts at 1 and is auto-incremented on each subsequent import. The mapping to a private key happens via the configuration in crypto.yaml. After the system has figured out (implicitly or explicitly) which certsign token it shall use, it looks up how to access the private key for that token. The private key that is the result of this inference is then used for the private key operation. This means that the definition in crypto.yaml must be consistent with the assignment of certsign tokens via openxpkiadm. In practice this primarily means that the PKI admin must make sure that the certsign token is set with the correct generation ID, and that the resulting token alias (consisting of group name and generation) is resolved to the matching private key. The behavior you observed seems to indicate that the system references an incorrect private key for the certsign token. How this did happen in your case depends on the administrative actions that happened before and how the private keys are referenced and used. Cheers Martin+ _______________________________________________ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
