I am actually trying to create a test ssl certifcate for my webserver.
I started with this tutorial.
But when I try to create a certificate with the following command:
openssl req -new -x509 -days 365 -sha1 -newkey rsa:1024 -nodes -keyout server.key -out server.crt -subj '/O=Company/OU=Department/CN=www.10.9.11.99/lebenmittel_test'
The following errors appears:
Generating a 1024 bit RSA private key
..............++++++
.................................++++++
writing new private key to 'server.key'
-----
end of string encountered while processing type of subject name element #3
problems making Certificate Request
I think the problem is, that I am trying to create a certificate for a IP address ... :/
I tried the same command with www.example.com and it worked.
Is there a way to create a certifcate for a IP address?
Your problem is that 'lebenmittel_test' is not a valid attribute syntax. Additionally, 'CN=www.10.9.11.99' is definitely dodgy for a CN.
Why not just assign a valid name for the CN, and then tweak your /etc/hosts file to point to the IP address using that name?
Related
Sometimes I test an SSL website on my local machine. I was tired to use a self-signed certificate and add them to my KeyChain on Mac (Browser or other OS). Moreover, Chrome always complains about them. Moreover, this approach was a bit different from the one used in production.
I found this article very useful where you create once your own CA root certificate, add it once to your keychain and then you use the CA private key to sign thousands of SSL test certificate for my local websites.
https://deliciousbrains.com/ssl-certificate-authority-for-local-https-development/
The tutorial works great but I would like to automate it. For the CA root certificate it was easy, I simply used the option -subj like this:
openssl req -x509 -new -nodes -key /certs/myCA.key -sha256 -days 1825 -subj "/C=$CA_COUNTRY/ST=$CA_STATE/L=$CA_CITY/O=$CA_ORGANIZATION/CN=$CA_COMMON_NAME" -out /certs/myCA2.pem
where the environment variable (CA_COUNTRY, CA_STATE, CA_CITY, CA_ORGANIZATION, CA_COMMON_NAME) are read from an external file.
However, when I tried to replicate the same thing for the website certificate I wasn't able to get the same result. The command is this:
openssl x509 -req -in dev.deliciousbrains.com.csr -CA myCA.pem -CAkey myCA.key -CAcreateserial -out dev.deliciousbrains.com.crt -days 825 -sha256 -extfile dev.deliciousbrains.com.ext
It seems that the -subj option doesn't work. Is there a way to pass the info above to this command and avoid interactive questions?
The command you show openssl x509 -req -CA/-CAkey ... does not ask any questions except the key password if there is one (which if you followed the instructions at the linked page there is). It is the preceding command to create the CSR openssl req -new that prompts for the subject name, and for that (like the command for creating the CA cert which is also req but with -x509 -- note -x509 is not the same as x509) you can use -subj. The statement on that page that "your answers don’t matter" isn't quite correct; it is true that when you use SubjectAlternativeName in the leaf cert, as that page advises/directs, the value of Subject is ignored for (at least) HTTPS server identification, but it must (still) be different from the name used for the CA to allow certificate validation to work. Standards allow the Subject name in a leaf cert to be empty when SAN is used (and empty is always different from nonempty and a nonempty name is required in the CA cert) but OpenSSL doesn't handle that case.
I have generated a self signed certificate using openSSL following commands
in my ubuntu based pc.
openssl req -x509 -newkey rsa:2048 -nodes -keyout key.pem -out cert.pem -pubkey -days 365 -subj "/C=NZ/ST=LH/O=SoN, Inc./CN=10.16.1.96" -reqexts Canada -config <(cat /etc/ssl/openssl.cnf <(printf "[Wellington]\nsubjectAltName=DNS:10.16.1.96,DNS:10.16.1.96"))
Next, I have copied the private key and cert.pem in the raspberrypi(10.16.1.96) which is running a webserver and using these keys.
Also, I have added the cert.pem in my chrome browser - Manage Certificates/Authorities, I have imported this certificate.
However, my browser complains about this -
Subject Alternative Name missing
The certificate for this site does not contain a Subject Alternative Name extension containing a domain name or IP address.
Certificate error
There are issues with the site's certificate chain (net::ERR_CERT_COMMON_NAME_INVALID).
How can I get rid of this error?
At the end of your command, you're providing subject alternative names like this: subjectAltName=DNS:10.16.1.96,DNS:10.16.1.96".
The problem is that you're using SANs of type dNSName (DNS: in the OpenSSL configuration), but you're using IP addresses, so you you need SANs of type iPAddress in this case (see this answer more details about the specifications).
Changing your command to use subjectAltName=IP:10.16.1.96,IP:10.16.1.96" should fix it.
As I don't know the openssl command's arguments by heart, I am used to referring to the same SO answer whenever I need to create self-signed certificates (for testing environments). The command looks like:
openssl req -x509 -nodes -newkey rsa:2048 -keyout mysite.key -out mysite.crt -days 365
And it usually works, for instance on my current Ubuntu 15.10. Today I'm on a fresh install of Debian Jessie and it doesn't. Apache warns at startup that:
[ssl:warn] [pid 1040] AH01906: www.mysite.com:443:0 server certificate is a CA certificate (BasicConstraints: CA == TRUE !?)
I looked for a solution to the problem and found an answer in a linux forum stating that the following should be used instead:
openssl genrsa -des3 -passout pass:x -out mysite.pass.key 2048
openssl rsa -passin pass:x -in mysite.pass.key -out mysite.key
openssl req -new -key mysite.key -out mysite.csr
openssl x509 -req -days 365 -in mysite.csr -signkey mysite.key -out mysite.crt
And it's true, this way the Apache warning disappears.
As far as I understand, this creates a passphrase-protected key, then removes the passphrase, then creates a CSR, then generates the certificate with both the CSR and the key.
So the question is: what does this longer version do that the shorter doesn't, and why is it necessary in some cases (like today for me)?
Short way (e.g. with OpenSSL 1.1.0f and Apache 2.4.37):
openssl genrsa -out notEncodedPk.key 3072
openssl req -new -out website.csr -sha256 -key notEncodedPk.key
openssl x509 -req -in website.csr -days 365 -signkey notEncodedPk.key -out website.cert -outform PEM
genrsa generates a 3072 bit RSA-Key. (The system should be online for some time to have good data in /dev/(u)random for seeding.) There is no need to generate an encrypted PK (1) and then use rsa to remove the password afterwards. (Maybe earlier versions of the tools required a password?)
req creates the certificate signing request and uses the PK for the signature. Providing something like -sha256 for the digest is optional. (3) Provide your infos in the interactive questionare. Ensure to put your site domain in "Common name:", otherwise the Apache will throw a warning (AH01909) and browsers will throw an "invalid certificate" message because the URL/domain does not match the certificate data (2). Leave "A challange password:" empty.
Use x509 to create a self-signed certificate with -signkey (the subject is copied to issuer). Normally the command works on certificates but with -req it accepts a CSR as an input. Then use your PK for signing the certificate. (-outform and -days are optional, with 30 days as the default value for the latter.)
Problem source:
As user207421 already stated: req creates a CSR OR it creates a self-signed root-CA-like certificate, therefore the typical tutorial tip
openssl req -x509 -nodes -days 365 -newkey rsa:3072 -sha256 -keyout website.key -out website.cert
is short but normally not what you want. You can also compare created certificates with
openssl x509 -text -noout -in website.cert
In the certificate, created with the single-line command, you see a section "X509v3 extensions:" with "X509v3 Basic Constraints: critical CA:TRUE". This is exactly the Apache warning message.
Instead, if you create the certificate with the three steps, the "X509v3 extensions:" section is not included into the certificate.
Appendix:
(1) Securing the PK with a password is a good idea in most cases. If the PK is stored without encryption, make sure to restrict access to root. If you use a password, you have to use the -passout/-passin options, but be aware that a simple "x" does not work anymore because some OpenSSL tools require at least 4 characters (otherwise: "result too small/bad password read"). Additionally in Apache you have to use something like SSLPassPhraseDialog buildin to manually enter the required password for the PK (or even for all PKs/certs) during Apache startup.
(2) Anyway, browsers will display a warning for self-signed certificates.
(3) Using SHA-1 would be inadequate for such a large RSA-key. In general, it is a good idea to review your openssl.conf, e.g. in Debian 9 in /etc/ssl/openssl.conf, which contains various defaults, for example signer_digest = sha256.
In the Debian 9 file, you also find in the [req] section a line x509_extensions=v3_ca and this is the reason, why the req command in combination with the -x509 option adds the CA-related extension (basicContraints=critical,CA:true), if used in the single-line style to create a self-signed certificate.
Addidionally you might notice a comment-line # req_extensions=v3_req. Because this line is commented out (in Debian 9 default openssl.cnf), the simple usage of the req command does not include any extensions.
Note that you might use this line in a modified file to add Subject Alternative Name's to the certificate, e.g. so it can handle multiple (sub-)domains (normally a much better choice than using e wildcard in CN, e.g. *.example.com).
complete CA and SSL creation / setup help:
I created my own CA cert and used it to load into browser (as CA authority) and sign my self-created SSL cert for my Apache_on_ubuntu website.
steps:
generate my CA private key:
# openssl genrsa -des3 -out /etc/ssl/private/myCA.key 2048
generate root certificate: *****send myCA.pem to all desktop/client browsers.
# openssl req -x509 -days 5475 -new -nodes -key /etc/ssl/private/myCA.key -sha256 -out /etc/ssl/certs/myCA.pem
Install the root CA in firefox. (cp myCA.pem to windows box)
in firefox: options -> privacy_&_security -> view_certificates -> certificate_manager -> Authorities -> import
Creating CA-Signed Certificates for Your Sites
4.1: create website private key:
# openssl genrsa -out /etc/ssl/private/www.mywebsite.com.key 2048
4.2: create website CSR: Note: answers don’t need to match the CA cert ans.
# openssl req -new -key /etc/ssl/private/www.mywebsite.com.key -out /etc/ssl/private/www.mywebsite.com.csr
4.3: Create config file: config file is needed to define the Subject Alternative Name (SAN) extension. "method to match a domain name against a certificate – using the available names within the subjectAlternativeName extension"
# vi /etc/ssl/private/www.mywebsite.com.ext
...............I have not used the ext file option.....(for hosting multiple SSL sites and certs on same host)
4.4: Create the certificate:
# openssl x509 -req -in /etc/ssl/private/www.mywebsite.com.csr -CA /etc/ssl/certs/myCA.pem -CAkey /etc/ssl/private/myCA.key -CAcreateserial -out /etc/ssl/certs/www.mywebsite.com.crt -days 5475 -sha256
create ssl-conf file:
# cat /etc/apache2/conf-available/ssl-params.conf
# modern configuration, tweak to your needs
SSLProtocol -all +TLSv1.2 +TLSv1.3
SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
SSLHonorCipherOrder on
SSLCompression off
SSLSessionTickets off
restart apache:
# systemctl restart apache2
Figure out which openssl.cnf you are using.
Select the correct section name that is doing your request.
Take out the CA:TRUE part (or change it to CA:FALSE) from the basicConstraint in the openssl.cnf that you are using.
Recreate the certificate the exact same way you did.
Your Apache webserver will no longer see a CA, much less a self-signed CA but just an ordinary self-signed certificate.
I had the same problem just today on Debian 9 stretch and I tried your solution to generate a new certificate using your method and it did not work. The warning in Apache was exactly the same.
I found out that the problem was that in my browser were stored other 6 certificates with the same FQDN. I erased the certificates and the problem has gone.
EDIT: Well, there's still the warning actually but at least everything is working.
openssl req creates a CSR or a CA root certificate. See the man page. It is not what you want. The second set of steps is correct.
I'm using amazon web service.
I'm using linux instance
I'm using GoDaddy SSL.
I'm following this steps:
http://jafty.com/blog/installing-godaddy-ssl-certificate-on-amazon-ec2/
I'm stuck at this point:
Generating a Certificate Signing Request (CSR) - Apache 2.x
Enter the following at the command prompt:openssl req -new -newkey rsa:2048 -nodes -keyout yourdomain.key -out yourdomain.csr Replace yourdomain with the domain name you're securing. For example, if your domain name is coolexample.com, you would type coolexample.key and coolexample.csr.
what I did was
openssl req -new -newkey rsa:2048 -nodes -keyout 180.21.80.1.key -out 180.21.80.1.csr
I used the public IP address of my t1 instance.
I have generated a key and CSR files.
180.21.80.1.key
180.21.80.1.csr
like this. Now its ready to copy and paste in go daddy.
my question is:
Is what I'm doing correct?
Do I have to create a name for my IP address, like domains?
Is it okay if I make mistakes? It's editable, right?
With reference to the link you mentioned try following steps
Ensure that you have installed mod_ssl and it is running.
Upload your certificates on Instance say /home/ec2-user/ssl
Edit /etc/httpd/conf.d/ssl.conf
Find below lines and replace accordingly (Verify the filename and
path are correct)
SSLCertificateFile /home/ec2-user/ssl/certs/site.com.crt
SSLCertificateKeyFile /home/ec2-user/ssl/keys/site.key
SSLCACertificateFile /home/ec2-user/ssl/ssl_files/gd_bundle.crt
Restart Apache
That looks right. Generally people don't use ip addresses as names of certs and csr's, they use hostnames, but I don't see why it wouldn't work. Also it's SUPER easy to add it to an ELB(aws load balancer) as opposed to configuring apache for it, so if you have your server(s) hidden behind an ELB, or you think you will add more servers at a later point it can be a little more convenient.
I've installed HAPRoxy 1.5-dev19, adn I am trying to bind using SSL.
I generated openssl certs in /etc/ssl/certs keys and validated that they are there and look good, and updated haproxy.cfg as below:
openssl req -nodes -x509 -newkey rsa:2048 -keyout /etc/ssl/certs/private.key -out /etc/ssl/certs/cert.pem -days 2000
frontend XRE
bind *:9045 ssl crt /etc/ssl/certs/private.key
But I still get:
parsing [/etc/haproxy/haproxy.cfg:48] : 'bind :443' : unable to load SSL certificate from PEM file '/etc/ssl/certs/private.key'.
Proxy 'haproxyLoopback': no SSL certificate specified for bind ':443' at [/etc/haproxy/haproxy.cfg:48] (use 'crt').
Your help is appreciated,
Many thanks,
Charlie
You are pointing the wrong file. It should be like this:
frontend XRE bind *:9045 ssl crt /etc/ssl/certs/cert.pem