3
$\begingroup$

I have got one theoretical question related to extensions of X509 Certificate. More precisely I have question about what is happening when issuer signs subject's certificate with has several extensions, especially I am interested in three extensions, certificate policies, issuer alternative names and basic constraints.

Is Issuer Alternative Names extension being filled with issuer's Subject Alternative Names extension when signing certificate?

Is Certificate Policies extension being unchanged when sign is done by issuer?

EDIT: I have given only an interface of application, where I should implement logic behind it. So I am given extensions fields which I can fill only when I generate initial self-signed certificate. Basic constraints comes with "is critical" checkbox, "is CA" checkbox and "path length" integer field. So I am confused when I fill those data when I generate self-signed, and when Issuer after that signs my previous certificate, what is happening with this extension.

Improve this question
$\endgroup$

1 Answer 1

Reset to default
2
$\begingroup$

The certificate policies are generally set by the CA. It is not something that is present within a certificate request (and if you would include it your request would hopefully be rejected or the included policies ignored).

Yes, the issuer alternative name would generally be identical to the subject alternative name of the parent certificate. But as the extension cannot be critical and isn't explicitly mentioned for certificate path validation, I see little reason to validate that it is.

You actually forgot to tell us that this is for a self signed certificate that you want to have signed.

This is not something you would usually do; in general you would generate a new key pair and certificate request and use that. Reusing the key pair is possible but should generally not be performed. It is not possible to change the issuer of a certificate without invalidating the previously set signature which includes this data element.

As for the criticality of the basic constraints: if you set the constraints it for a self signed leaf certificate rather than a root CA certificate I would set "is critical" to true (anything will parse these two constraints by now), "is CA" to false and finally path length constraint simply to 0.

If you do send your self signed cert to a CA and it will process your cert, then it will probably simply ignore the values set.

Improve this answer
$\endgroup$
3
  • $\begingroup$ I have edited my question. Feel free to ask for more info in case I wasn't precise enough. Thanks in advance. $\endgroup$
    – Lululu
    May 28, 2017 at 15:30
  • $\begingroup$ Thanks for answer. It is bit confusing because I've got some fields which I should fill, but in real only CA would fill them. Only one more thing if I set "is CA" to true and length to 10 when self-signing (I must self-sign due to Java implementation), what will CA do after signing certificate, will it modify constraints? $\endgroup$
    – Lululu
    May 28, 2017 at 15:50
  • $\begingroup$ A general CA will never issue a leaf certificate where the CA flag is true. Now if you want to become an intermediate CA yourself you may just be required to do a little bit more... :) Unless the CA itself f*cks it up. Again, they should expect a certificate request where these fields are not available rather than a self signed certificate though. $\endgroup$
    – Maarten Bodewes ♦
    May 28, 2017 at 16:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.