New answers tagged

-2

I managed to put the SAN in CSR and then sign it without losing them, by doing the following. Find the openssl.cnf In Ubuntu /etc/ssl/openssl.cnf CentOS /etc/pki/tls/openssl.cnf And uncomment the following under the [ CA_default ] section copy_extensions = copy Then you have to create some files (if you don't know where, try issuing the first cert, ...


1

[v3_req_client] extendedKeyUsage = clientAuth subjectAltName = @alt_names This section is not referenced anywhere. It will not be magically be used either. You have to explicitly provide what it should be used for, same as you did for [req_distinguished_name] with distinguished_name = req_distinguished_name: req_extensions = v3_req_client


1

As you are purchasing these certificates, the contents of these fields will probably be governed by the user interface of the certificate seller which will hopefully carry out some sanity check on the values you enter. The information you should place in the Subject field depends on the application amongst other things. HTTPS, which is just an ...


3

For security purposes, a certificate's signature must sign the entire certificate (aside from the signature itself, obviously...). Otherwise, you could take a validly-issued certificate for your own domain (and for which you hold the corresponding private key), change the "Subject" (the entity - such as a domain like "yoursite.com" - that the certificate ...


7

The signature covers the certificate, not only the public key. If the signature covered only the public key, you could change any parameter (expiration date, domain name, issuer) and the signature would still be valid. Digital signatures are not encryption: https://security.stackexchange.com/a/87373/70830 It is important, when reading the link above, to ...


3

For OCSP? I'm guessing it's for OCSP. I've had a look at the CAB forum Baseline Requirements. I did a full text search for digitalSignature and there are only two hits. Hit 1/2 is for root CAs: b. keyUsage This extension MUST be present and MUST be marked critical. Bit positions for keyCertSign and cRLSign MUST be set. If the Root CA Private Key is ...


3

I think you're right. RFC 5280 section 4.2.1.3. Key Usage says (emphasis mine): KeyUsage ::= BIT STRING { digitalSignature (0), nonRepudiation (1), -- recent editions of X.509 have -- renamed this bit to contentCommitment keyEncipherment (2), dataEncipherment (3), ...


Top 50 recent answers are included