Cross-signing non-self-signed third party certificate

[David von Oheimb]

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
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20230602/10bef3c0/attachment.htm>