Re: Cross-signing non-self-signed third party certificate

[David von Oheimb <it@xxxxxxxxxxxxx>]

I agree with Yannik that there is no compelling reason for 

generally refusing to re-sign a non-self-signed certificate.

Correct that doing so, any existing AKID will need to be removed, or better replaced.

BTW, the x509 app already contains code filtering out both AKID and SKID extensions
when converting a certificate to a PKCS#10 CSR.
In that use case the self-signedness does make sense, and I suspect that the restriction
on the input cert being self-signed historically stems from that use case.

Can well be that there are further cert fields which also would require some treatment,
but this is at the discretion of the new issuer,
and to this end some further support by the app would be nice but hard to do generally.

(BTW, using a subject OU for expressing usage policies, as given below as an example,
is anyway an abuse of that RDN field, and would be a good candidate for removal.)

David

On Thu, 2023-06-01 at 20:40 -0400, Viktor Dukhovni wrote:

On Mon, May 29, 2023 at 03:25:35PM +0200, Yannik Sembritzki via openssl-users wrote:

I am trying to cross-sign a third party certificate which is *not* self 

signed (e.g. a third party intermediate CA, or even a particular client 

certificate) like this:

/openssl x509 -in third-party.crt -CA /etc/pki/r1/ca.crt -CAkey 

/etc/pki/r1/private/ca.key -out third-party-cross-signed.crt -set_serial 

1000/

This results in the following error: /Error with certificate to be 

certified - should be self-signed//

/

The same thing works for signing third-party root CAs (as they are 

self-signed), but that might be too broad in some situations.

Could anybody explain the reason for this restriction?

One possible reason is that the certificates issued by the CA in

question could have AKID extensions that specify the serial

number of the issuing CA certificate and *its* issuer DN.

Any such certificates would not validate with a cross-signed

chain that replaces the parent issuer.

On Thu, 2023-06-01 at 19:51 +0200, Yannik Sembritzki via openssl-users wrote:

On 30.05.23 14:26, Jochen Bern wrote:

1. The cert (or, for that matter, CSR) being *self* signed serves as

   proof that the requesting party is in possession of the private key.

2. You want to sign info on the subject you verified, not someone else's

   interpretation of the subject; e.g., a person's cert from a 3rd party

   CA giving the OU as "FooBar E-Mail-Reply Verified Personal

   Certificates" is unlikely to correctly state the dpt. the person

   works in. (Assuming that you would want to copy *anything* beyond the

   pubkey from the preexisting cert into the new one, of course.)

Hi Jochen,

While these points may be relevant in some environments, I don't think

of them as enough reason to completely forbid users from cross-signing

non-self-signed certificates.

Finally, this should be up to the user.

In our specific use case, it is us wanting to trust part of a third

party pki, but restrict this trust by cross-signing with a name

constraint. The third party may not be very interested in this ("simply

import our ca as is"), but we want to do it, because internal pkis are

not held to the same standard as public CAs which are bound by the

CA/Browser Forum Baseline requirements.

Best regards

Yannik