Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
How to generate CSR for mult-domain.
I found that generating CSR for single domain is as below:
openssl req -new -newkey rsa:2048 -nodes -keyout yourdomain.key -out yourdomain.csr
But how do I generate CSR multi-domain
For an X.509 certificate to support multiple domains, it must use multiple Subject Alternative Name DNS entries, according to RFC 2818 (HTTP over TLS) (or RFC 6125):
If a subjectAltName extension of type dNSName is present, that MUST
be used as the identity. Otherwise, the (most specific) Common Name
field in the Subject field of the certificate MUST be used. Although
the use of the Common Name is existing practice, it is deprecated and
Certification Authorities are encouraged to use the dNSName instead.
Matching is performed using the matching rules specified by
[RFC2459]. If more than one identity of a given type is present in
the certificate (e.g., more than one dNSName name, a match in any one
of the set is considered acceptable.)
As described in this document (except I would use -des3 too for the genrsa command, to protect the private key):
Make a copy your initial openssl.cnf file (the original is probably somewhere under /etc on Linux).
Edit it to add req_extensions = v3_req in the [ req ] section.
Edit it to add subjectAltName=DNS:www.example.com,DNS:www.other-example.com (one DNS: entry per host name you require) in the [ v3_req ] section.
Make OpenSSL use that configuration file. Call it with OPENSSL_CONF=/path/to/your/openssl.cnf openssl req ...
This being said, I wouldn't worry too much about setting any extension in the CSR. Any good CA should ignore whatever you've set in the CSR and only set whatever they have actually verified when issuing the actual certificate. They'll happily replace any RDN in your Subject DN (e.g. Country, Organization, ...) as well as any extension (SAN or Key Usage). Firstly, if they let any extension as requested in the CSR by the applicant, this would be a security risk, since some applicants could really get anything. Secondly, that's how they make extra money, by charging you for setting a few bits here and there (e.g. code signing extension): they'll make sure that you only get what you've paid for in your certificate. I understand, though, that you may want to put all the names you request in your CSR, just to be sure.
Related
I have generated my certificate using:
openssl genrsa -out ca.key 2048
openssl req -new -x509 -key ca.key -out ca.crt
The certificates have been created.
How do I display the extended validation certificate when I access for example "http://localhost/Web/"
Also note that I am using WampServer
I have generated mt certificated using [OpenSSL]...
How do I display the extended validation certificate when I access for example "http://localhost/Web/"
You can't because its not present.
First, OpenSSL generally conforms to the IETF's standards. There is no concept of extended validation.
Second, extended validation offers nothing by way of security (that is, there are no additional security controls to place that utilize it). EV is also known as "PKI ME Harder". The race to the bottom meant CAs had to stop validating regular certificates correctly because they could not maintain service on the declining profits. EV restores the profit levels and the validations that were always supposed to be occurring.
Third, the extended validation information is in the Cert Policy extension, and the IETF does not require it. See OID for certificates issued under IETF policy? on the PKIX mailing list.
Fourth, extended validation is provided by the CA/Browser Forums in the Extended Validation Guidelines.
Fifth, there is no one OID to cover extended validation. Each CA provides their own OID. See Extended Validation certificate identification.
Finally, OpenSSL does not issue certificates in accordance with the CA/BF EV Guidelines.
If a certificate includes the Cert Policy extension, then you can display it with the following. It prints all the information in a certificate:
openssl x509 -in server-cert.pem -text -noout
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 8 years ago.
Improve this question
what is different between 2 command in open ssl tools?
openssl genrsa -des3 -out privkey.pem 2048 and openssl genrsa -out privkey.pem 2048?
thanks
The -des3 option specifies how the private key is encrypted with a password. Without a cipher option, the private key is not encrypted, and no password is required.
Password encryption can protect the private key even when file-system–based access control is circumvented.
According to the docs:
-aes128|-aes192|-aes256|-camellia128|-camellia192|-camellia256|-des|-des3|-idea
These options encrypt the private key with specified cipher before
outputting it. If none of these options is specified no encryption is
used. If encryption is used a pass phrase is prompted for if it is not
supplied via the -passout argument.
DES is an encryption method and DES3 (also called triple DES) is the same method that is ran 3 times in a row to make the encryption stronger.
DES3 is a standard that is being heavily used (-des3), for example, when your browser is being redirected to port 443 (SSL), after the RSA key exchange, DES3 is being used (with the RSA key) for the rest of the session.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 9 years ago.
Improve this question
I've just bought comodo essential wildcard certificate, they asked me to generate csr to activate it.
As i understood, i need to:
Generate RSA 2048bit private key
Generate CSR based on it
As i see, openssl genrsa command accepts different encryption params:
-des encrypt the generated key with DES in cbc mode -des3 encrypt the generated key with DES in ede cbc mode (168 bit key)
-aes128,
-aes192,
-aes256
What should i use?
The encryption param of openssl genrsa command is used to specify which algorithm to use for encrypting your private key (using the password you specify).
CSR (Certificate Signing Request) includes your public key and some additional public information to be included into certificate. CSR never includes a private key.
So, choice of algorithm for encrypting the private key is completely unrelated to CSR. Choose whatever you prefer. AES variants and Triple-DES (-des3) should be preferred; plain DES is usually considered not secure these days. Also see why AES is more secure than DES. But I think algorithm choice in this particular case is not as important as using a strong password and protecting it.
Note: remember that if you protect your private key with a password, you will be prompted to enter the password every time you want to access the private key, such as when starting your web server. If you forget the password, your private key is effectively lost and you must generate a new key and request a new certificate. You could generate a private key without encryption (without password): openssl genrsa -out filename.key 2048. It is also possible to remove the password (effectively, store it unencrypted) at any time using command like this: openssl rsa -in encrypted.key -out unencrypted.key. You’ll need the password for that (you will be prompted to enter it).
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I use OpenSSL on ubuntu to generate a CSR file that I will paste to the SSL certificate provider. when I paste the code, I see an unknown e-mail addreses to select but not the e-mail address I have entered during csr creation.
Where does OpenSSL get this email addresses, like postmaster#mydomain.com, admin#mydomain.com.
The command that I use is:
sudo openssl req -out csr.csr -new -newkey rsa:2048 -nodes -keyout private.key
The point is that most Certificate Authorities ("certificate provider") ignore the e-mail address from the CSR itself, since it is user provided input and thus not trustworthy.
The e-mail addresses presented to you during the application process are
from the Admin-C WHOIS record of the domain for which you are applying a certificate for
some standard addresses which are assumed to usually exist for most domains (postmaster#, admin#, ..)
This is done by the CA to prevent fraud and ensure that only someone with access to the domain is able to buy a certificate for it.
You can't change that. You can:
Either configure one of the presented e-mail addresses on your domain and fetch the confirmat e-mail from there
Or, if possible, change your Admin-C records e-mail address (which will take a while)
I'm confused about something in the SSL renewal process using WHM/cPanel for an existing Comodo Extended Validation cert.
We have been issued a replacement certificate by Comodo without - I believe - every submitting a CSR for them. I say "I believe" because there are 3 people with access to WHM for this server, but I'm assured that no one has been fiddling in the last year.
Does this sound possible? CAN a cert be supplied without a CSR if it's a replacement? I will attempt to get hold of Comodo but being a weekend, and seeing that the old cert runs out in a day I thought I'd consult the stackHiveMind :)
More info:
As a test, I've tried to install the new cert and 'fetch' the existing private key, but when I try to submit that I get the following error:
SSL install aborted due to error: Modulus mismatch, key file does not match certificate. Please use the correct key file
In some cases, yes, you can. Assuming you have an RSA private key in PEM format, this will extract the public key (it won't generate a certificate):
openssl rsa -in key.pem -pubout -out pubkey.pem
This will create a new CSR with the public key, obtained from the private key file.
openssl req -new -key key.pem -out host.csr
Note that, strictly speaking, a CA doesn't need you to submit a CSR to issue a certificate. All it needs is the public key (to which it will have access through your existing cert). It could potentially attach any Subject DN and attribute and issue it as a certificate without any need to contact you. Of course such practices might be incompatible with their policies, but technically, it's possible. The CSR is merely a convenient format for you to send a public key to request a certificate, and submit the name and attributes you would like (which you all sign together).
SSL install aborted due to error: Modulus mismatch, key file does not
match certificate. Please use the correct key file
Provided you've done the certificate operations properly, this could indicate that the new certificate you've been issued has been issued against a different key-pair than yours. This could indicate foul play, because someone else could have issued a CSR with their own key-pair and have had this certificate issued to them (which could be quite worrying since you're talking of an EV cert too, which is supposed to have additional protections against this.)
I would suggest checking with your colleagues if any have requested a new certificate or contacting your CA to find out why you've received a new certificate. Renewing the certificate using the previous public key might be part of their existing package. If it's using the same public key, it's not a problem, although it's better practice to change the key material, i.e. submit a CSR coming from a new key-pair, when renewing a certificate.