<html><head></head><body><div>I agree with Yannik that there is no compelling reason for </div><div>generally refusing to re-sign a non-self-signed certificate.</div><div><br></div><div>Correct that doing so, any existing AKID will need to be removed, or better replaced.</div><div>BTW, the x509 app already contains code filtering out both AKID and SKID extensions<br>when converting a certificate to a PKCS#10 CSR.<br>In that use case the self-signedness does make sense, and I suspect that the restriction<br>on the input cert being self-signed historically stems from that use case.</div><div><br></div><div>Can well be that there are further cert fields which also would require some treatment,<br>but this is at the discretion of the new issuer,<br>and to this end some further support by the app would be nice but hard to do generally.</div><div>(BTW, using a subject OU for expressing usage policies, as given below as an example,<br>is anyway an abuse of that RDN field, and would be a good candidate for removal.)</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>David</div><div><br></div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: Cantarell; font-size: 14.666667px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-tap-highlight-color: rgba(0, 0, 0, 0.4); -webkit-text-stroke-width: 0px; text-decoration: none;">On Thu, 2023-06-01 at 20:40 -0400, Viktor Dukhovni wrote:</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div>On Mon, May 29, 2023 at 03:25:35PM +0200, Yannik Sembritzki via openssl-users wrote:<br></div><div><br></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div>I am trying to cross-sign a third party certificate which is *not* self<span class="Apple-converted-space"> </span><br></div><div>signed (e.g. a third party intermediate CA, or even a particular client<span class="Apple-converted-space"> </span><br></div><div>certificate) like this:<br></div><div><br></div><div>/openssl x509 -in third-party.crt -CA /etc/pki/r1/ca.crt -CAkey<span class="Apple-converted-space"> </span><br></div><div>/etc/pki/r1/private/ca.key -out third-party-cross-signed.crt -set_serial<span class="Apple-converted-space"> </span><br></div><div>1000/<br></div><div><br></div><div>This results in the following error: /Error with certificate to be<span class="Apple-converted-space"> </span><br></div><div>certified - should be self-signed//<br></div><div>/<br></div><div>The same thing works for signing third-party root CAs (as they are<span class="Apple-converted-space"> </span><br></div><div>self-signed), but that might be too broad in some situations.<br></div><div><br></div><div>Could anybody explain the reason for this restriction?<br></div></blockquote><div><br></div><div>One possible reason is that the certificates issued by the CA in<br></div><div>question could have AKID extensions that specify the serial<br></div><div>number of the issuing CA certificate and *its* issuer DN.<br></div><div><br></div><div>Any such certificates would not validate with a cross-signed<br></div><div>chain that replaces the parent issuer.</div></blockquote><div><span></span></div><div><br></div><div>On Thu, 2023-06-01 at 19:51 +0200, Yannik Sembritzki via openssl-users wrote:</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div>On 30.05.23 14:26, Jochen Bern wrote:<br></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div>1. The cert (or, for that matter, CSR) being *self* signed serves as<br></div><div> proof that the requesting party is in possession of the private key.<br></div><div>2. You want to sign info on the subject you verified, not someone else's<br></div><div> interpretation of the subject; e.g., a person's cert from a 3rd party<br></div><div> CA giving the OU as "FooBar E-Mail-Reply Verified Personal<br></div><div> Certificates" is unlikely to correctly state the dpt. the person<br></div><div> works in. (Assuming that you would want to copy *anything* beyond the<br></div><div> pubkey from the preexisting cert into the new one, of course.)<br></div></blockquote><div><br></div><div>Hi Jochen,<br></div><div><br></div><div>While these points may be relevant in some environments, I don't think <br></div><div>of them as enough reason to completely forbid users from cross-signing <br></div><div>non-self-signed certificates.<br></div><div>Finally, this should be up to the user.<br></div><div><br></div><div>In our specific use case, it is us wanting to trust part of a third <br></div><div>party pki, but restrict this trust by cross-signing with a name <br></div><div>constraint. The third party may not be very interested in this ("simply <br></div><div>import our ca as is"), but we want to do it, because internal pkis are <br></div><div>not held to the same standard as public CAs which are bound by the <br></div><div>CA/Browser Forum Baseline requirements.<br></div><div><br></div><div>Best regards<br></div><div>Yannik<br></div><div><br></div></blockquote></body></html>