Jakob Bohm wrote: > On 1/7/2014 12:17 AM, Biondo, Brandon A. wrote: >> I am using ‘ca’ not ‘x509’. It too ignores/discards extensions. Turning >> on copy_extensions solved the issue though, thanks. I have some >> follow-up questions: >> >> 1.If including SANs in CSRs is non-standard, what is the accepted way of >> passing all the metadata you want to an authority to construct your >> certificate? >> > > Many commercial CAs take all the certificate information "out-of-band" > on a web form, the only thing those CAs use from the CSR is that it is > signed with the requested public/private key pair and has the right > subject.
First of all there is no real established standard. Even PKIX WG defined CMP/CRMF and CMC which are implemented with different flavors. >> 2.Why does the config file say to be careful using copy_extensions? Why >> wouldn’t you want all your extensions to be part of your certificate? >> Isn’t the whole point of a CSR to package up all the data you want in >> your certificate? >> > > Because copy-extensions copies all the extensions in the CSR, so if you > use it, you will need to carefully check every extension in every CSR you > receive from "users". Note that security-wise, you should not blindly trust a > CSR from a less secure computer than the CA computer, There's nothing wrong with a CA accepting PKCS#10 CSRs with subjectAltName values provided it checks the input as it has to check every input anyway. The advantage of taking input from the subjectAltName in the CSR is that it's signed by the EE's private key. Ciao, Michael.
smime.p7s
Description: S/MIME Cryptographic Signature
