I'm setting up a mysql server and am trying to have a mysql client connect to it over SSL. I'm going to be using a self signed certificate for the same. Reading the MySQL documentation on setting up SSL I see that I have to specify the path to the following files :-
the SSL root CA
the SSL certificate
the SSL private key
In this particular case, should I be setting both the root CA and the certificate to my self signed certificate?
Example of how to create properly a Self-Signed SSL Certificate.
Su to root and create a directory that only the root account has access to.
su -
mkdir certificates
chmod 700 certificates
cd certificates
Use openssl to generate a server key
openssl genrsa -des3 -out server.key 4096
Openssl will request a pass phrase. Type in a sentence that is long and complex but that you can remember (you'll have to type it at least twice). Try to make it at least 40 characters long, with punctuation and capital and lowercase letters. The more different characters you use the better.
Then create the certificate signing request with the server key you created in step 2.
openssl req -new -key server.key -out server.csr
Sign your certificate using SSL.
openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt
You can set your certificate for any number of days, but I recommend 365 so that you remember to update it once a year.
Once you're done, you'll have the following files:
server.crt: The self-signed server certificate
server.csr: Server certificate signing request
server.key: The private server key, does not require a password when starting Apache
Place those files where they are required for your Web server, and turn on HTTPS. (If you don't know how, contact your server administrator.)
Related
I simulate a CA on a centos7 host(azcn-gs1-nginx2), and use the CA to sign a certificate for a server(azcn-gs1-nginx1).
Below are what I do:
On CA azcn-gs1-nginx1, generate key
cd /etc/pki/CA/private/
openssl genrsa -aes128 -out testCA.key 2048
Generate CA certificate
openssl req -new -x509 -days 1825 -key /etc/pki/CA/private/testCA.key -out /etc/pki/CA/certs/testCA.crt
On the server azcn-gs1-nginx2, generate private key and certificate sign request.
openssl genrsa -out /etc/pki/tls/private/newServer.key 1024
openssl req -new -key /etc/pki/tls/private/newServer.key -out /etc/pki/tls/newServer.csr
Copy newServer.csr to CA host for signing.
scp /etc/pki/tls/newServer.csr root#azcn-gs1-nginx2:~/newServer.csr
On CA host, sign the newServer.csr, and copy back the newServer.crt
to server azcn-gs1-nginx2.
openssl x509 -req -in ./newServer.csr -CA /etc/pki/CA/certs/testCA.crt -CAkey /etc/pki/CA/private/testCA.key -CAcreateserial -out newServer.crt -days 1461
scp newServer.crt root#azcn-gs1-nginx2:/etc/pki/tls/certs/newServer.crt
Server azcn-gs1-nginx2 is a reverse proxy for a webservice. I configure the newServer.key and newServer.crt in Nginx for https.
ssl_certificate /etc/pki/tls/certs/newServer_1.crt;
ssl_certificate_key /etc/pki/tls/private/newServer.key;
I am on another Ubuntu host. I import the CA's certificate testCA.crt into Ubuntu truststore, as below:
cp testCA.crt /usr/local/share/ca-certificates/
update-ca-certificates
The Ubuntu's built-in browser is firefox. I also import testCA.crt
into firefox's truststore. Please see attached pic.
I open firefox browser and visit web server by https. Expected result is it can directly open webpage without security warning.
Unfortunately, it gives warning of "Your connection is not secure.....".
and, looks like the certificate only contains the certificate itself. It doesn't not contain CA's certificate.
Why this happen? How can I get a signed certificate with the CA's certificate in Chain?
Thanks & regards,
Jie
Thanks for your comments.
That's right.
Actually, it is very simple. The 2 .crt files of CA and server can be concatenated into one .crt. Then the certificate chain is a whole.
Right, the pictures of 2 and 3 are other problems.
Thanks,
Jie
i am trying to create a self signed certificate using openssl following the docs https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/configuring-https-ssl.html
i tried to add the generated private and public pem files to my NLB TCP listener as a self signed certificate and it is failing with the below exception.
Error creating listener The imported certificate's configuration is not compatible and will not appear in the list of available certificates for your listeners. Select or upload a different certificate and try again.
I saw that NLB allows RSA 2048 certs. Not sure why the console is showing the error display.
You need to generate a RSA 1024 or 2028 certificate. check the valid certificates that ACM supports. i used the below commands to generate the self signed certificate
openssl genrsa -out private-key.pem 1024
openssl rsa -in private-key.pem -pubout -out public-key.pem
openssl req -new -x509 -key private-key.pem -out cert.pem -days 3600
mention the country, state and domain name. I initially missed the domain name because of which NLB listener wasn't accepting the certificate.
I am trying to understand the relationship between the client and server in the context of an SSL connection. Am I correct in understanding that the fact that the same certificate authority (me - in example below) sign both server and client certificate makes that they can communicate. Thus, that the server only accepts communication when client authenticates with client certificate signed by the same CA as the server certificate, and this is essential to the idea of an SSL connection?
(script underneath comes directly from http://blog.nategood.com/client-side-certificate-authentication-in-ngi)
# Create the CA Key and Certificate for signing Client Certs
openssl genrsa -des3 -out ca.key 4096
openssl req -new -x509 -days 365 -key ca.key -out ca.crt
# Create the Server Key, CSR, and Certificate
openssl genrsa -des3 -out server.key 1024
openssl req -new -key server.key -out server.csr
# We're self signing our own server cert here. This is a no-no in production.
openssl x509 -req -days 365 -in server.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out server.crt
# Create the Client Key and CSR
openssl genrsa -des3 -out client.key 1024
openssl req -new -key client.key -out client.csr
# Sign the client certificate with our CA cert. Unlike signing our own server cert, this is what we want to do.
openssl x509 -req -days 365 -in client.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out client.crt
server {
listen 443;
ssl on;
server_name example.com;
ssl_certificate /etc/nginx/certs/server.crt;
ssl_certificate_key /etc/nginx/certs/server.key;
ssl_client_certificate /etc/nginx/certs/ca.crt;
ssl_verify_client on;
The short answer is No. These are two separate aspects.
Here:
ssl_certificate /etc/nginx/certs/server.crt;
ssl_certificate_key /etc/nginx/certs/server.key;
You are configuring the server certificates which need to be trusted by the client.
And here:
ssl_client_certificate /etc/nginx/certs/ca.crt;
You configure the certification authority to verify your clients' certificates against.
"Must server and client certificate be signed by same CA in SSL"
Short answer is, it can be but not necessary.
To see why, let's break down the steps but without too much technical.
From your point of view when setting up the nginx server.
You want to achieve 2 goals.
Prove the identity of your server.
For this you get a CA to sign your server certificate and
present it to a client that connects to your server
Verify the identity of the client connecting to the server
For this, you set define the list of CA that you trust that signs the client's certificate.
When a client connects to your server, you check if the client certificate presented is signed by your list of CA
That's not the end. Let's look at the client's end.
The client also wants to achieve 2 goals.
Prove the client's identity when connecting to your server
For this, the client get a CA to sign its client certificate and
present it to your server when connecting.
Here is the catch, the CA that signs the client certificate must be in your server's list of CA.
Verify the identity of your server
For this, the client has to trust the CA that signs your server's certificate.
How is this done?
Typically this list is predefine on the system or browser so it happens transparently.
But if you are writing a client, then you may have to define this list of trusted CA or just let the client know the CA that signs your server certificate.
So, it can happen that the CA signing the server and the client is the same but it is not necessary. It all depends on the list of CA defined on both the server and the client.
Server certs and Client certs are used in completely different ways.
The only similarities are:
They both contain the word certificate
They both use public & private keys for encryption
I have Tomcat-Apache set up to serve my application using 443(Apache).
Configured Apache for root certificate and key for enabling HTTPS access for my application.
On server i had to install this certificate to user personal store for HTTPS access.
Problem is if client wants to access he needs to manually install the certificate first. These are self signed certificates generated via openSSL.
openssl req -new -x509 -days 1024 -key ca.key -out ca.crt -config openssl.cnf
Is there a way to configure Apache, or install certificate in another store for client to trigger auto installation of certificate while accessing the site?
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.