How to serve a Vue application over HTTPS for local development - vue.js

I need to serve a vue application over HTTPS while doing local development.
The application is being served with: npm run serve which runs: vue-cli-service serve
I have tried to create a vue.config.js file and add the following to it:
module.exports = {
devServer: {
port: 8080,
https: true,
}
}
This results in console errors in Chrome v75 such as the following: GET https://192.168.0.71:8080/sockjs-node/info?t=1564339649757 net::ERR_CERT_AUTHORITY_INVALID I'm guessing this is Chrome saying that the certificate being used when setting https to true isn't from a valid CA (maybe it's some sort of self signed thing going on in the background?)
How can I get around this? Is generating certificates via "Let's Encrypt" probably the way to go?
On another note, I have also generated a root CA private key using openssl genrsa -des3 -out rootCA.key 2048 and a self signed certificate using openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 1024 -out rootCA.pem, but I'm not sure how to tell the vue-cli-service to try and use these. However, if self signed certificates result in ERR_CERT_AUTHORITY_INVALID errors in Chrome, then there isn't much point pursuing this route

Go to your network tab in the Chrome console.
Double click on the failing https://192.168.0.71:8080/sockjs-node/info?t=1564339649757 (Opens in new tab)
Accept exemption for the invalid cert

What I ended up doing was creating a shell script with this in it:
echo "Started local certificate setup script."
openssl genrsa -des3 -out rootCA.key 2048
openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 825 -out rootCA.pem
openssl req -new -sha256 -nodes -out server.csr -newkey rsa:2048 -keyout server.key -config server.csr.cnf
openssl x509 -req -in server.csr -CA rootCA.pem -CAkey rootCA.key -CAcreateserial -out server.crt -days 825 -sha256 -extfile v3.ext
echo "Trust the certificate (add it to the system keychain): "
sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain rootCA.pem
Basically you create a root CA and have it sign your cert.
Note: the "security add-trusted-cert" step will have to be modified if you aren't on macOS. This step adds it to the macOS keychain.
v3.ext contains:
authorityKeyIdentifier = keyid, issuer
basicConstraints = CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
subjectAltName = #alt_names
[alt_names]
DNS.1 = localhost
server.csr.cnf contains:
[req]
default_bits = 2048
prompt = no
default_md = sha256
distinguished_name = dn
[dn]
C=CA
ST=RandomProvince
L=RandomCity
O=RandomOrg
OU=RandomOrgUnit
emailAddress=admin#somedomain.com
CN = localhost
If you're including this in your project, then you'll probably also want to add the following entries to .gitignore:
*.key
*.srl
*.csr
*.pem
*.crt
In my config file (I'm using nuxt.js now) I have the following:
server: {
port: 7000,
host: 'localhost',
timing: false,
https: {
// these files are generated by running the above shell script
key: fs.readFileSync(path.resolve(__dirname, 'server.key')),
cert: fs.readFileSync(path.resolve(__dirname, 'server.crt')),
},
},
Having a script do this is nice so that team members that might not be familiar with this sort of crypto stuff don't have to dig into the details too much and can just start writing code!

Not too sure what your webpack configuration is, but mine has a dev-server.js file inside the build folder. To make https work on the local machine, I had to replace the line const server = app.listen(port) with the following code:
const https = require('https');
const fs = require('fs');
const options = {
key: fs.readFileSync('./certs/server.key'),
cert: fs.readFileSync('./certs/server.cert')
}
const server = https.createServer(options, app).listen(port);
Note that you might need to change the path to your certificates.
Also change const uri = 'http://localhost:' + port to const uri = 'https://localhost:' + port

As long as you have, at least, self signed certificates and keys then all you would have to do is run the command "npm run serve --https"

LEts Encrypt solved it for me. I just generated a certificate for my localhost, added that to gitignore and snap. Error gone. Try this: https://letsencrypt.org/docs/certificates-for-localhost/

You can use mkcert https://github.com/FiloSottile/mkcert
It will create a fake CA certificate for your localhost and you can configure your local server to use it

simply add this into your vue.config.js
module.exports = {
...
devServer: {
https: true
}
}

Related

How to use self signed certificates in Postman?

I am using Postman to test my API. I am using self-signed certificates to use HTTPS in my application.
After I turn on the HTTPS setup, the postman app shows this error
it shows
Error: self signed certificate
The API calls works perfectly when I turn off the SSL certificate verification in the postman setting. I tried to install certificate/keys in postman app but it didn't work.
I want to use the certificate/keys in postman so that I can hit the APIs using SSL. Is there any way to do that?
Generate RootCA.pem, RootCA.key & RootCA.crt:
openssl req -x509 -nodes -new -sha256 -days 1024 -newkey rsa:2048 -keyout RootCA.key -out RootCA.pem -subj "/C=BR/CN=Example-Root-CA"
openssl x509 -outform pem -in RootCA.pem -out RootCA.crt
customize waht you want...(C=?,CN=? etc)
Domain name certificate
Add your domain myapp.local that is hosted on your local machine for development (using the hosts file to point them to 127.0.0.1).
127.0.0.1 myapp.local
First, create a file domains.ext that lists all your local domains:
authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
subjectAltName = #alt_names
[alt_names]
DNS.1 = localhost
DNS.2 = myapp.local
Generate localhost.key, localhost.csr, and localhost.crt:
openssl req -new -nodes -newkey rsa:2048 -keyout localhost.key -out localhost.csr -subj "/C=BR/ST=BAHIA/L=SSA/O=Example-Certificates/CN=localhost.local"
openssl x509 -req -sha256 -days 1024 -in localhost.csr -CA RootCA.pem -CAkey RootCA.key -CAcreateserial -extfile domains.ext -out localhost.crt
openssl pkcs12 -export -inkey localhost.key -in localhost.crt -out localhost.p12
customize waht you want...(C=?,CN=? etc)
For p12 uses 'password'. This was my keystore on springboot app for example:
Confguring a Keystore (used PKCS12 format, maybe a JKS format also acceptable)...
https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#howto-configure-ssl
cp localhost.p12 myapp/src/main/resources/keystore/localhost.p12
edit application.properties
# secure server port
server.port=8443
# The format used for the keystore. It could be set to JKS in case it is a JKS file
server.ssl.key-store-type=PKCS12
# The path to the keystore containing the certificate
server.ssl.key-store=classpath:keystore/localhost.p12
# The password used to generate the certificate
server.ssl.key-store-password=password
# Enable ssl
server.ssl.enabled=true
Trust the local CA
At this point, the site would load with a warning about self-signed certificates. In order to get a green lock, your new local CA has to be added to the trusted Root Certificate Authorities.
In Postman go to:
Settings -> Enable SSL certificate verification: ON.
Settings -> Certifcates -> CA Certificates: add the PEM RootCA.pem
In a curl command line:
curl --cacert RootCA.crt -v https://myapp.local:8449/endpoint

How to use SSL with Vue CLI for local development?

I understand to use https with Vue CLI I can set "https: true" under devServer in a vue.config.js file, but I also need a self signed certificate.
I've tried generating a self signed one using OpenSSL and using the following in my vue.config.js file to target:
const fs = require('fs');
module.exports = {
devServer: {
port: '8081',
https: {
key: fs.readFileSync('./certs/server.key'),
cert: fs.readFileSync('./certs/server.cert'),
},
},
};
Chrome confirms it's using my certificate but still shows https as "Not secure"
How can I make chrome assess my self signed certificate as secure when providing it via Vue CLI?
Simply enter this in your Chrome
chrome://flags/#allow-insecure-localhost
Set to Enabled, restart Chrome, and you're good to go.
My problem was that everybody talks about putting the cert properties in the "https" child configuration node, but this doesn't work, you hve to put it in the devServer config node:
module.exports = {
devServer: {
port: '8081',
https: {
key: fs.readFileSync('./certs/server.key'),
--> this is WRONG
This is the correct way:
module.exports = {
devServer: {
disableHostCheck: true,
port:8080,
host: 'xxxxxx',
https: true,
//key: fs.readFileSync('./certs/xxxxxx.pem'),
//cert: fs.readFileSync('./certs/xxxxxx.pem'),
pfx: fs.readFileSync('./certs/xxxxxx.pfx'),
pfxPassphrase: "xxxxxx",
public: 'https://xxxxxx:9000/',
https: true,
hotOnly: false,
}
}
Use the network path rather than loopback or localhost. For example
https://192.168.2.210:8080/
works fine, while
https://localhost:8080/ and https://127.0.0.1:8080 balk at the certificate problem.
You are doing right, but you also have to add the self-signed cert inside certification authorities of your browser, as it is self-signed.
Instead of using a self-signed certificate, you can also create a root certificate, and then generate a localhost or other server identifier certificate. I recommend this solution because this way you can generate certificates for all non production environments and import only one custom certification authority.
There are many sites where you can find how to do it, one of them I think it's very clear is How to create an HTTPS certificate for localhost domains. Basically you have to follow these steps described in that link:
Generate certification authority key:
openssl req -x509 -nodes -new -sha256 -days 1024 -newkey rsa:2048 -keyout RootCA.key -out RootCA.pem -subj "/C=US/CN=Example-Root-CA"
Here we have to change the parameters as we wish, mainly -sub parameter.
Generate certificate for certification authority
openssl x509 -outform pem -in RootCA.pem -out RootCA.crt
Generate key for localhost
openssl req -new -nodes -newkey rsa:2048 -keyout localhost.key -out localhost.csr -subj "/C=US/ST=YourState/L=YourCity/O=Example-Certificates/CN=localhost.local"
Where you have to change -subj as you need or leave it that way.
Generate localhost certificate by creating a certificate config file and request openssl to generate it.
This is the certificate config file:
authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
subjectAltName = #alt_names
[alt_names]
DNS.1 = localhost
DNS.2 = fake1.local
DNS.3 = fake2.local
And this is the command to generate the certificate:
openssl x509 -req -sha256 -days 1024 -in localhost.csr -CA RootCA.pem -CAkey RootCA.key -CAcreateserial -extfile domains.ext -out localhost.crt
Once you have the certificate, you have to import the certification authority on your preferred browser. You can, also, follow 3 and 4 steps for every server or virtual machine you need for development and use them without needing to import new certification authorities in your browser.
If you have legit certificates Chad Carter gives a good explanation here: https://stackoverflow.com/a/57226788/2363056
The steps are as follows:
create vue.config.js in your projects root (if not there already)
add the following code to it:
const fs = require('fs')
module.exports = {
devServer: {
port:8080,
host: 'example.com',
https: true,
key: fs.readFileSync('/etc/ssl/keys/example.com.pem'),
cert: fs.readFileSync('/etc/ssl/keys/example.com/cert.pem'),
https: true,
hotOnly: false,
}
}
when serving your project, ensure https is enabled (ie. $ vue-cli-service serve --https true)
I use the mkcert to create trusted https cert on windows OS.
mkcert.
Last thing you should do is openning your OS explorer, click the install.bat file

telegram getwebhookinfo returns "SSL error {SSL routines:tls_process_server_certificate:certificate verify failed}" [duplicate]

Closed. This question is not about programming or software development. 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 4 months ago.
The community reviewed whether to reopen this question 3 months ago and left it closed:
Original close reason(s) were not resolved
Improve this question
I'm adding HTTPS support to an embedded Linux device. I have tried to generate a self-signed certificate with these steps:
openssl req -new > cert.csr
openssl rsa -in privkey.pem -out key.pem
openssl x509 -in cert.csr -out cert.pem -req -signkey key.pem -days 1001
cat key.pem>>cert.pem
This works, but I get some errors with, for example, Google Chrome:
This is probably not the site you are looking for!
The site's security certificate is not trusted!
Am I missing something? Is this the correct way to build a self-signed certificate?
You can do that in one command:
openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -sha256 -days 365
You can also add -nodes (short for "no DES") if you don't want to protect your private key with a passphrase. Otherwise it will prompt you for "at least a 4 character" password.
The days parameter (365) you can replace with any number to affect the expiration date. It will then prompt you for things like "Country Name", but you can just hit Enter and accept the defaults.
Add -subj '/CN=localhost' to suppress questions about the contents of the certificate (replace localhost with your desired domain).
Self-signed certificates are not validated with any third party unless you import them to the browsers previously. If you need more security, you should use a certificate signed by a certificate authority (CA).
As of 2023 with OpenSSL ≥ 1.1.1, the following command serves all your needs, including Subject Alternate Name (SAN):
openssl req -x509 -newkey rsa:4096 -sha256 -days 3650 -nodes \
-keyout example.key -out example.crt -subj "/CN=example.com" \
-addext "subjectAltName=DNS:example.com,DNS:www.example.net,IP:10.0.0.1"
On old systems with OpenSSL ≤ 1.1.0, such as Debian ≤ 9 or CentOS ≤ 7, a longer version of this command needs to be used:
openssl req -x509 -newkey rsa:4096 -sha256 -days 3650 -nodes \
-keyout example.key -out example.crt -extensions san -config \
<(echo "[req]";
echo distinguished_name=req;
echo "[san]";
echo subjectAltName=DNS:example.com,DNS:www.example.net,IP:10.0.0.1
) \
-subj "/CN=example.com"
Either command creates a certificate that is
valid for the (sub)domains example.com and www.example.net (SAN),
also valid for the IP address 10.0.0.1 (SAN),
relatively strong (as of 2023) and
valid for 3650 days (~10 years).
The following files are generated:
Private key: example.key
Certificate: example.crt
All information is provided at the command line. There is no interactive input that annoys you. There are no config files you have to mess around with. All necessary steps are executed by a single OpenSSL invocation: from private key generation up to the self-signed certificate.
Remark #1: Crypto parameters
Since the certificate is self-signed and needs to be accepted by users manually, it doesn't make sense to use a short expiration or weak cryptography.
In the future, you might want to use more than 4096 bits for the RSA key and a hash algorithm stronger than sha256, but as of 2023 these are sane values. They are sufficiently strong while being supported by all modern browsers.
Remark #2: Parameter "-nodes"
Theoretically you could leave out the -nodes parameter (which means "no DES encryption"), in which case example.key would be encrypted with a password. However, this is almost never useful for a server installation, because you would either have to store the password on the server as well, or you'd have to enter it manually on each reboot.
Remark #3: See also
Provide subjectAltName to openssl directly on command line
How to add multiple email addresses to an SSL certificate via the command line?
More information about MSYS_NO_PATHCONV
Am I missing something? Is this the correct way to build a self-signed certificate?
It's easy to create a self-signed certificate. You just use the openssl req command. It can be tricky to create one that can be consumed by the largest selection of clients, like browsers and command line tools.
It's difficult because the browsers have their own set of requirements, and they are more restrictive than the IETF. The requirements used by browsers are documented at the CA/Browser Forums (see references below). The restrictions arise in two key areas: (1) trust anchors, and (2) DNS names.
Modern browsers (like the warez we're using in 2014/2015) want a certificate that chains back to a trust anchor, and they want DNS names to be presented in particular ways in the certificate. And browsers are actively moving against self-signed server certificates.
Some browsers don't exactly make it easy to import a self-signed server certificate. In fact, you can't with some browsers, like Android's browser. So the complete solution is to become your own authority.
In the absence of becoming your own authority, you have to get the DNS names right to give the certificate the greatest chance of success. But I would encourage you to become your own authority. It's easy to become your own authority, and it will sidestep all the trust issues (who better to trust than yourself?).
This is probably not the site you are looking for!
The site's security certificate is not trusted!
This is because browsers use a predefined list of trust anchors to validate server certificates. A self-signed certificate does not chain back to a trusted anchor.
The best way to avoid this is:
Create your own authority (i.e., become a CA)
Create a certificate signing request (CSR) for the server
Sign the server's CSR with your CA key
Install the server certificate on the server
Install the CA certificate on the client
Step 1 - Create your own authority just means to create a self-signed certificate with CA: true and proper key usage. That means the Subject and Issuer are the same entity, CA is set to true in Basic Constraints (it should also be marked as critical), key usage is keyCertSign and crlSign (if you are using CRLs), and the Subject Key Identifier (SKI) is the same as the Authority Key Identifier (AKI).
To become your own certificate authority, see *How do you sign a certificate signing request with your certification authority? on Stack Overflow. Then, import your CA into the Trust Store used by the browser.
Steps 2 - 4 are roughly what you do now for a public facing server when you enlist the services of a CA like Startcom or CAcert. Steps 1 and 5 allows you to avoid the third-party authority, and act as your own authority (who better to trust than yourself?).
The next best way to avoid the browser warning is to trust the server's certificate. But some browsers, like Android's default browser, do not let you do it. So it will never work on the platform.
The issue of browsers (and other similar user agents) not trusting self-signed certificates is going to be a big problem in the Internet of Things (IoT). For example, what is going to happen when you connect to your thermostat or refrigerator to program it? The answer is, nothing good as far as the user experience is concerned.
The W3C's WebAppSec Working Group is starting to look at the issue. See, for example, Proposal: Marking HTTP As Non-Secure.
How to create a self-signed certificate with OpenSSL
The commands below and the configuration file create a self-signed certificate (it also shows you how to create a signing request). They differ from other answers in one respect: the DNS names used for the self signed certificate are in the Subject Alternate Name (SAN), and not the Common Name (CN).
The DNS names are placed in the SAN through the configuration file with the line subjectAltName = #alternate_names (there's no way to do it through the command line). Then there's an alternate_names section in the configuration file (you should tune this to suit your taste):
[ alternate_names ]
DNS.1 = example.com
DNS.2 = www.example.com
DNS.3 = mail.example.com
DNS.4 = ftp.example.com
# Add these if you need them. But usually you don't want them or
# need them in production. You may need them for development.
# DNS.5 = localhost
# DNS.6 = localhost.localdomain
# IP.1 = 127.0.0.1
# IP.2 = ::1
It's important to put DNS name in the SAN and not the CN, because both the IETF and the CA/Browser Forums specify the practice. They also specify that DNS names in the CN are deprecated (but not prohibited). If you put a DNS name in the CN, then it must be included in the SAN under the CA/B policies. So you can't avoid using the Subject Alternate Name.
If you don't do put DNS names in the SAN, then the certificate will fail to validate under a browser and other user agents which follow the CA/Browser Forum guidelines.
Related: browsers follow the CA/Browser Forum policies; and not the IETF policies. That's one of the reasons a certificate created with OpenSSL (which generally follows the IETF) sometimes does not validate under a browser (browsers follow the CA/B). They are different standards, they have different issuing policies and different validation requirements.
Create a self signed certificate (notice the addition of -x509 option):
openssl req -config example-com.conf -new -x509 -sha256 -newkey rsa:2048 -nodes \
-keyout example-com.key.pem -days 365 -out example-com.cert.pem
Create a signing request (notice the lack of -x509 option):
openssl req -config example-com.conf -new -sha256 -newkey rsa:2048 -nodes \
-keyout example-com.key.pem -days 365 -out example-com.req.pem
Print a self-signed certificate:
openssl x509 -in example-com.cert.pem -text -noout
Print a signing request:
openssl req -in example-com.req.pem -text -noout
Configuration file (passed via -config option)
[ req ]
default_bits = 2048
default_keyfile = server-key.pem
distinguished_name = subject
req_extensions = req_ext
x509_extensions = x509_ext
string_mask = utf8only
# The Subject DN can be formed using X501 or RFC 4514 (see RFC 4519 for a description).
# Its sort of a mashup. For example, RFC 4514 does not provide emailAddress.
[ subject ]
countryName = Country Name (2 letter code)
countryName_default = US
stateOrProvinceName = State or Province Name (full name)
stateOrProvinceName_default = NY
localityName = Locality Name (eg, city)
localityName_default = New York
organizationName = Organization Name (eg, company)
organizationName_default = Example, LLC
# Use a friendly name here because it's presented to the user. The server's DNS
# names are placed in Subject Alternate Names. Plus, DNS names here is deprecated
# by both IETF and CA/Browser Forums. If you place a DNS name here, then you
# must include the DNS name in the SAN too (otherwise, Chrome and others that
# strictly follow the CA/Browser Baseline Requirements will fail).
commonName = Common Name (e.g. server FQDN or YOUR name)
commonName_default = Example Company
emailAddress = Email Address
emailAddress_default = test#example.com
# Section x509_ext is used when generating a self-signed certificate. I.e., openssl req -x509 ...
[ x509_ext ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
# You only need digitalSignature below. *If* you don't allow
# RSA Key transport (i.e., you use ephemeral cipher suites), then
# omit keyEncipherment because that's key transport.
basicConstraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment
subjectAltName = #alternate_names
nsComment = "OpenSSL Generated Certificate"
# RFC 5280, Section 4.2.1.12 makes EKU optional
# CA/Browser Baseline Requirements, Appendix (B)(3)(G) makes me confused
# In either case, you probably only need serverAuth.
# extendedKeyUsage = serverAuth, clientAuth
# Section req_ext is used when generating a certificate signing request. I.e., openssl req ...
[ req_ext ]
subjectKeyIdentifier = hash
basicConstraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment
subjectAltName = #alternate_names
nsComment = "OpenSSL Generated Certificate"
# RFC 5280, Section 4.2.1.12 makes EKU optional
# CA/Browser Baseline Requirements, Appendix (B)(3)(G) makes me confused
# In either case, you probably only need serverAuth.
# extendedKeyUsage = serverAuth, clientAuth
[ alternate_names ]
DNS.1 = example.com
DNS.2 = www.example.com
DNS.3 = mail.example.com
DNS.4 = ftp.example.com
# Add these if you need them. But usually you don't want them or
# need them in production. You may need them for development.
# DNS.5 = localhost
# DNS.6 = localhost.localdomain
# DNS.7 = 127.0.0.1
# IPv6 localhost
# DNS.8 = ::1
You may need to do the following for Chrome. Otherwise Chrome may complain a Common Name is invalid (ERR_CERT_COMMON_NAME_INVALID). I'm not sure what the relationship is between an IP address in the SAN and a CN in this instance.
# IPv4 localhost
# IP.1 = 127.0.0.1
# IPv6 localhost
# IP.2 = ::1
There are other rules concerning the handling of DNS names in X.509/PKIX certificates. Refer to these documents for the rules:
RFC 5280, Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
RFC 6125, Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)
RFC 6797, Appendix A, HTTP Strict Transport Security (HSTS)
RFC 7469, Public Key Pinning Extension for HTTP
CA/Browser Forum Baseline Requirements
CA/Browser Forum Extended Validation Guidelines
RFC 6797 and RFC 7469 are listed, because they are more restrictive than the other RFCs and CA/B documents. RFCs 6797 and 7469 do not allow an IP address, either.
Here are the options described in #diegows's answer, described in more detail, from the documentation:
openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days XXX
req
PKCS#10 certificate request and certificate generating utility.
-x509
this option outputs a self signed certificate instead of a certificate request.
This is typically used to generate a test certificate or a self signed root CA.
-newkey arg
this option creates a new certificate request and a new private key. The argument
takes one of several forms. rsa:nbits, where nbits is the number of bits,
generates an RSA key nbits in size.
-keyout filename
this gives the filename to write the newly created private key to.
-out filename
This specifies the output filename to write to or standard output by default.
-days n
when the -x509 option is being used this specifies the number of days to certify
the certificate for. The default is 30 days.
-nodes
if this option is specified then if a private key is created it will not be encrypted.
The documentation is actually more detailed than the above; I just summarized it here.
I can't comment, so I will put this as a separate answer. I found a few issues with the accepted one-liner answer:
The one-liner includes a passphrase in the key.
The one-liner uses SHA-1 which in many browsers throws warnings in console.
Here is a simplified version that removes the passphrase, ups the security to suppress warnings and includes a suggestion in comments to pass in -subj to remove the full question list:
openssl genrsa -out server.key 2048
openssl rsa -in server.key -out server.key
openssl req -sha256 -new -key server.key -out server.csr -subj '/CN=localhost'
openssl x509 -req -sha256 -days 365 -in server.csr -signkey server.key -out server.crt
Replace 'localhost' with whatever domain you require. You will need to run the first two commands one by one as OpenSSL will prompt for a passphrase.
To combine the two into a .pem file:
cat server.crt server.key > cert.pem
Modern browsers now throw a security error for otherwise well-formed self-signed certificates if they are missing a SAN (Subject Alternate Name). OpenSSL does not provide a command-line way to specify this, so many developers' tutorials and bookmarks are suddenly outdated.
The quickest way to get running again is a short, stand-alone conf file:
Create an OpenSSL config file (example: req.cnf)
[req]
distinguished_name = req_distinguished_name
x509_extensions = v3_req
prompt = no
[req_distinguished_name]
C = US
ST = VA
L = SomeCity
O = MyCompany
OU = MyDivision
CN = www.company.com
[v3_req]
keyUsage = critical, digitalSignature, keyAgreement
extendedKeyUsage = serverAuth
subjectAltName = #alt_names
[alt_names]
DNS.1 = www.company.com
DNS.2 = company.com
DNS.3 = company.net
Create the certificate referencing this config file
openssl req -x509 -nodes -days 730 -newkey rsa:2048 \
-keyout cert.key -out cert.pem -config req.cnf -sha256
Example config from https://support.citrix.com/article/CTX135602
I would recommend to add the -sha256 parameter, to use the SHA-2 hash algorithm, because major browsers are considering to show "SHA-1 certificates" as not secure.
The same command line from the accepted answer - #diegows with added -sha256
openssl req -x509 -sha256 -newkey rsa:2048 -keyout key.pem -out cert.pem -days XXX
More information in Google Security blog.
Update May 2018. As many noted in the comments that using SHA-2 does not add any security to a self-signed certificate. But I still recommend using it as a good habit of not using outdated / insecure cryptographic hash functions. Full explanation is available in Why is it fine for certificates above the end-entity certificate to be SHA-1 based?.
I can`t comment so I add a separate answer.
I tried to create a self-signed certificate for NGINX and it was easy, but when I wanted to add it to Chrome white list I had a problem. And my solution was to create a Root certificate and signed a child certificate by it.
So step by step.
Create file config_ssl_ca.cnf
Notice, config file has an option basicConstraints=CA:true which means that this certificate is supposed to be root.
This is a good practice, because you create it once and can reuse.
[ req ]
default_bits = 2048
prompt = no
distinguished_name=req_distinguished_name
req_extensions = v3_req
[ req_distinguished_name ]
countryName=UA
stateOrProvinceName=root region
localityName=root city
organizationName=Market(localhost)
organizationalUnitName=roote department
commonName=market.localhost
emailAddress=root_email#root.localhost
[ alternate_names ]
DNS.1 = market.localhost
DNS.2 = www.market.localhost
DNS.3 = mail.market.localhost
DNS.4 = ftp.market.localhost
DNS.5 = *.market.localhost
[ v3_req ]
keyUsage=digitalSignature
basicConstraints=CA:true
subjectKeyIdentifier = hash
subjectAltName = #alternate_names
Next config file for your child certificate will be call config_ssl.cnf.
[ req ]
default_bits = 2048
prompt = no
distinguished_name=req_distinguished_name
req_extensions = v3_req
[ req_distinguished_name ]
countryName=UA
stateOrProvinceName=Kyiv region
localityName=Kyiv
organizationName=market place
organizationalUnitName=market place department
commonName=market.localhost
emailAddress=email#market.localhost
[ alternate_names ]
DNS.1 = market.localhost
DNS.2 = www.market.localhost
DNS.3 = mail.market.localhost
DNS.4 = ftp.market.localhost
DNS.5 = *.market.localhost
[ v3_req ]
keyUsage=digitalSignature
basicConstraints=CA:false
subjectAltName = #alternate_names
subjectKeyIdentifier = hash
The first step - create Root key and certificate
openssl genrsa -out ca.key 2048
openssl req -new -x509 -key ca.key -out ca.crt -days 365 -config config_ssl_ca.cnf
The second step creates child key and file CSR - Certificate Signing Request. Because the idea is to sign the child certificate by root and get a correct certificate
openssl genrsa -out market.key 2048
openssl req -new -sha256 -key market.key -config config_ssl.cnf -out market.csr
Open Linux terminal and do this command
echo 00 > ca.srl
touch index.txt
The ca.srl text file containing the next serial number to use in hex.
Mandatory. This file must be present and contain a valid serial number.
Last Step, create one more config file and call it config_ca.cnf
# we use 'ca' as the default section because we're usign the ca command
[ ca ]
default_ca = my_ca
[ my_ca ]
# a text file containing the next serial number to use in hex. Mandatory.
# This file must be present and contain a valid serial number.
serial = ./ca.srl
# the text database file to use. Mandatory. This file must be present though
# initially it will be empty.
database = ./index.txt
# specifies the directory where new certificates will be placed. Mandatory.
new_certs_dir = ./
# the file containing the CA certificate. Mandatory
certificate = ./ca.crt
# the file contaning the CA private key. Mandatory
private_key = ./ca.key
# the message digest algorithm. Remember to not use MD5
default_md = sha256
# for how many days will the signed certificate be valid
default_days = 365
# a section with a set of variables corresponding to DN fields
policy = my_policy
# MOST IMPORTANT PART OF THIS CONFIG
copy_extensions = copy
[ my_policy ]
# if the value is "match" then the field value must match the same field in the
# CA certificate. If the value is "supplied" then it must be present.
# Optional means it may be present. Any fields not mentioned are silently
# deleted.
countryName = match
stateOrProvinceName = supplied
organizationName = supplied
commonName = market.localhost
organizationalUnitName = optional
commonName = supplied
You may ask, why so difficult, why we must create one more config to sign child certificate by root. The answer is simple because child certificate must have a SAN block - Subject Alternative Names.
If we sign the child certificate by "openssl x509" utils, the Root certificate will delete the SAN field in child certificate.
So we use "openssl ca" instead of "openssl x509" to avoid the deleting of the SAN field. We create a new config file and tell it to copy all extended fields copy_extensions = copy.
openssl ca -config config_ca.cnf -out market.crt -in market.csr
The program asks you 2 questions:
Sign the certificate? Say "Y"
1 out of 1 certificate requests certified, commit? Say "Y"
In terminal you can see a sentence with the word "Database", it means file index.txt which you create by the command "touch". It will contain all information by all certificates you create by "openssl ca" util.
To check the certificate valid use:
openssl rsa -in market.key -check
If you want to see what inside in CRT:
openssl x509 -in market.crt -text -noout
If you want to see what inside in CSR:
openssl req -in market.csr -noout -text
This is the script I use on local boxes to set the SAN (subjectAltName) in self-signed certificates.
This script takes the domain name (example.com) and generates the SAN for *.example.com and example.com in the same certificate. The sections below are commented. Name the script (e.g. generate-ssl.sh) and give it executable permissions. The files will be written to the same directory as the script.
Chrome 58 an onward requires SAN to be set in self-signed certificates.
#!/usr/bin/env bash
# Set the TLD domain we want to use
BASE_DOMAIN="example.com"
# Days for the cert to live
DAYS=1095
# A blank passphrase
PASSPHRASE=""
# Generated configuration file
CONFIG_FILE="config.txt"
cat > $CONFIG_FILE <<-EOF
[req]
default_bits = 2048
prompt = no
default_md = sha256
x509_extensions = v3_req
distinguished_name = dn
[dn]
C = CA
ST = BC
L = Vancouver
O = Example Corp
OU = Testing Domain
emailAddress = webmaster#$BASE_DOMAIN
CN = $BASE_DOMAIN
[v3_req]
subjectAltName = #alt_names
[alt_names]
DNS.1 = *.$BASE_DOMAIN
DNS.2 = $BASE_DOMAIN
EOF
# The file name can be anything
FILE_NAME="$BASE_DOMAIN"
# Remove previous keys
echo "Removing existing certs like $FILE_NAME.*"
chmod 770 $FILE_NAME.*
rm $FILE_NAME.*
echo "Generating certs for $BASE_DOMAIN"
# Generate our Private Key, CSR and Certificate
# Use SHA-2 as SHA-1 is unsupported from Jan 1, 2017
openssl req -new -x509 -newkey rsa:2048 -sha256 -nodes -keyout "$FILE_NAME.key" -days $DAYS -out "$FILE_NAME.crt" -passin pass:$PASSPHRASE -config "$CONFIG_FILE"
# OPTIONAL - write an info to see the details of the generated crt
openssl x509 -noout -fingerprint -text < "$FILE_NAME.crt" > "$FILE_NAME.info"
# Protect the key
chmod 400 "$FILE_NAME.key"
This script also writes an information file, so you can inspect the new certificate and verify the SAN is set properly.
...
28:dd:b8:1e:34:b5:b1:44:1a:60:6d:e3:3c:5a:c4:
da:3d
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Alternative Name:
DNS:*.example.com, DNS:example.com
Signature Algorithm: sha256WithRSAEncryption
3b:35:5a:d6:9e:92:4f:fc:f4:f4:87:78:cd:c7:8d:cd:8c:cc:
...
If you are using Apache, then you can reference the above certificate in your configuration file like so:
<VirtualHost _default_:443>
ServerName example.com
ServerAlias www.example.com
DocumentRoot /var/www/htdocs
SSLEngine on
SSLCertificateFile path/to/your/example.com.crt
SSLCertificateKeyFile path/to/your/example.com.key
</VirtualHost>
Remember to restart your Apache (or Nginx, or IIS) server for the new certificate to take effect.
2017 one-liner:
openssl req \
-newkey rsa:2048 \
-x509 \
-nodes \
-keyout server.pem \
-new \
-out server.pem \
-subj /CN=localhost \
-reqexts SAN \
-extensions SAN \
-config <(cat /System/Library/OpenSSL/openssl.cnf \
<(printf '[SAN]\nsubjectAltName=DNS:localhost')) \
-sha256 \
-days 3650
This also works in Chrome 57, as it provides the SAN, without having another configuration file.
It was taken from an answer here.
This creates a single .pem file that contains both the private key and cert. You can move them to separate .pem files if needed.
Generate a key without password and certificate for 10 years, the short way:
openssl req -x509 -nodes -new -keyout server.key -out server.crt -days 3650 -subj "/C=/ST=/L=/O=/OU=web/CN=www.server.com"
for the flag -subj | -subject empty values are permitted -subj "/C=/ST=/L=/O=/OU=web/CN=www.server.com", but you can sets more details as you like:
C - Country Name (2 letter code)
ST - State
L - Locality Name (eg, city)
O - Organization Name
OU - Organizational Unit Name
CN - Common Name - required!
One-liner version 2017:
CentOS:
openssl req -x509 -nodes -sha256 -newkey rsa:2048 \
-keyout localhost.key -out localhost.crt \
-days 3650 \
-subj "CN=localhost" \
-reqexts SAN -extensions SAN \
-config <(cat /etc/pki/tls/openssl.cnf <(printf "\n[SAN]\nsubjectAltName=IP:127.0.0.1,DNS:localhost"))
Ubuntu:
openssl req -x509 -nodes -sha256 -newkey rsa:2048 \
-keyout localhost.key -out localhost.crt \
-days 3650 \
-subj "/CN=localhost" \
-reqexts SAN -extensions SAN \
-config <(cat /etc/ssl/openssl.cnf <(printf "\n[SAN]\nsubjectAltName=IP:127.0.0.1,DNS:localhost"))
Edit: added prepending Slash to 'subj' option for Ubuntu.
openssl allows to generate self-signed certificate by a single command (-newkey
instructs to generate a private key and -x509 instructs to issue a self-signed
certificate instead of a signing request)::
openssl req -x509 -newkey rsa:4096 \
-keyout my.key -passout pass:123456 -out my.crt \
-days 365 \
-subj /CN=localhost/O=home/C=US/emailAddress=me#mail.internal \
-addext "subjectAltName = DNS:localhost,DNS:web.internal,email:me#mail.internal" \
-addext keyUsage=digitalSignature -addext extendedKeyUsage=serverAuth
You can generate a private key and construct a self-signing certificate in separate steps::
openssl genrsa -out my.key -passout pass:123456 2048
openssl req -x509 \
-key my.key -passin pass:123456 -out my.csr \
-days 3650 \
-subj /CN=localhost/O=home/C=US/emailAddress=me#mail.internal \
-addext "subjectAltName = DNS:localhost,DNS:web.internal,email:me#mail.internal" \
-addext keyUsage=digitalSignature -addext extendedKeyUsage=serverAuth
Review the resulting certificate::
openssl x509 -text -noout -in my.crt
Java keytool creates PKCS#12 store::
keytool -genkeypair -keystore my.p12 -alias master \
-storetype pkcs12 -keyalg RSA -keysize 2048 -validity 3650 \
-storepass 123456 \
-dname "CN=localhost,O=home,C=US" \
-ext 'san=dns:localhost,dns:web.internal,email:me#mail.internal'
To export the self-signed certificate::
keytool -exportcert -keystore my.p12 -file my.crt \
-alias master -rfc -storepass 123456
Review the resulting certificate::
keytool -printcert -file my.crt
certtool from GnuTLS doesn't allow passing different attributes from CLI. I don't like to mess with config files ((
Generate keys
I am using /etc/mysql for cert storage because /etc/apparmor.d/usr.sbin.mysqld contains /etc/mysql/*.pem r.
sudo su -
cd /etc/mysql
openssl genrsa -out ca-key.pem 2048;
openssl req -new -x509 -nodes -days 1000 -key ca-key.pem -out ca-cert.pem;
openssl req -newkey rsa:2048 -days 1000 -nodes -keyout server-key.pem -out server-req.pem;
openssl x509 -req -in server-req.pem -days 1000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 -out server-cert.pem;
openssl req -newkey rsa:2048 -days 1000 -nodes -keyout client-key.pem -out client-req.pem;
openssl x509 -req -in client-req.pem -days 1000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 -out client-cert.pem;
Add configuration
/etc/mysql/my.cnf
[client]
ssl-ca=/etc/mysql/ca-cert.pem
ssl-cert=/etc/mysql/client-cert.pem
ssl-key=/etc/mysql/client-key.pem
[mysqld]
ssl-ca=/etc/mysql/ca-cert.pem
ssl-cert=/etc/mysql/server-cert.pem
ssl-key=/etc/mysql/server-key.pem
On my setup, Ubuntu server logged to: /var/log/mysql/error.log
Follow up notes:
SSL error: Unable to get certificate from '...'
MySQL might be denied read access to your certificate file if it is not in apparmors configuration. As mentioned in the previous steps^, save all our certificates as .pem files in the /etc/mysql/ directory which is approved by default by apparmor (or modify your apparmor/SELinux to allow access to wherever you stored them.)
SSL error: Unable to get private key
Your MySQL server version may not support the default rsa:2048 format
Convert generated rsa:2048 to plain rsa with:
openssl rsa -in server-key.pem -out server-key.pem
openssl rsa -in client-key.pem -out client-key.pem
Check if local server supports SSL:
mysql -u root -p
mysql> show variables like "%ssl%";
+---------------+----------------------------+
| Variable_name | Value |
+---------------+----------------------------+
| have_openssl | YES |
| have_ssl | YES |
| ssl_ca | /etc/mysql/ca-cert.pem |
| ssl_capath | |
| ssl_cert | /etc/mysql/server-cert.pem |
| ssl_cipher | |
| ssl_key | /etc/mysql/server-key.pem |
+---------------+----------------------------+
Verifying a connection to the database is SSL encrypted:
Verifying connection
When logged in to the MySQL instance, you can issue the query:
show status like 'Ssl_cipher';
If your connection is not encrypted, the result will be blank:
mysql> show status like 'Ssl_cipher';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Ssl_cipher | |
+---------------+-------+
1 row in set (0.00 sec)
Otherwise, it would show a non-zero length string for the cypher in use:
mysql> show status like 'Ssl_cipher';
+---------------+--------------------+
| Variable_name | Value |
+---------------+--------------------+
| Ssl_cipher | DHE-RSA-AES256-SHA |
+---------------+--------------------+
1 row in set (0.00 sec)
Require ssl for specific user's connection ('require ssl'):
SSL
Tells the server to permit only SSL-encrypted connections for the account.
GRANT ALL PRIVILEGES ON test.* TO 'root'#'localhost'
REQUIRE SSL;
To connect, the client must specify the --ssl-ca option to authenticate the server certificate, and may additionally specify the --ssl-key and --ssl-cert options. If neither --ssl-ca option nor --ssl-capath option is specified, the client does not authenticate the server certificate.
Alternate link: Lengthy tutorial in Secure PHP Connections to MySQL with SSL.
One liner FTW. I like to keep it simple. Why not use one command that contains ALL the arguments needed? This is how I like it - this creates an x509 certificate and its PEM key:
openssl req -x509 \
-nodes -days 365 -newkey rsa:4096 \
-keyout self.key.pem \
-out self-x509.crt \
-subj "/C=US/ST=WA/L=Seattle/CN=example.com/emailAddress=someEmail#gmail.com"
That single command contains all the answers you would normally provide for the certificate details. This way you can set the parameters and run the command, get your output - then go for coffee.
>> More here <<
You have the general procedure correct. The syntax for the command is below.
openssl req -new -key {private key file} -out {output file}
However, the warnings are displayed, because the browser was not able to verify the identify by validating the certificate with a known Certificate Authority (CA).
As this is a self-signed certificate there is no CA and you can safely ignore the warning and proceed. Should you want to get a real certificate that will be recognizable by anyone on the public Internet then the procedure is below.
Generate a private key
Use that private key to create a CSR file
Submit CSR to CA (Verisign or others, etc.)
Install received cert from CA on web server
Add other certs to authentication chain depending on the type cert
I have more details about this in a post at Securing the Connection: Creating a Security Certificate with OpenSSL
As has been discussed in detail, self-signed certificates are not trusted for the Internet. You can add your self-signed certificate to many but not all browsers. Alternatively you can become your own certificate authority.
The primary reason one does not want to get a signed certificate from a certificate authority is cost -- Symantec charges between $995 - $1,999 per year for certificates -- just for a certificate intended for internal network, Symantec charges $399 per year. That cost is easy to justify if you are processing credit card payments or work for the profit center of a highly profitable company. It is more than many can afford for a personal project one is creating on the internet, or for a non-profit running on a minimal budget, or if one works in a cost center of an organization -- cost centers always try to do more with less.
An alternative is to use certbot (see about certbot). Certbot is an easy-to-use automatic client that fetches and deploys SSL/TLS certificates for your web server.
If you setup certbot, you can enable it to create and maintain a certificate for you issued by the Let’s Encrypt certificate authority.
I did this over the weekend for my organization. I installed the required packages for certbot on my server (Ubuntu 16.04) and then ran the command necessary to setup and enable certbot. One likely needs a DNS plugin for certbot - we are presently using DigitalOcean though may be migrating to another service soon.
Note that some of the instructions were not quite right and took a little poking and time with Google to figure out. This took a fair amount of my time the first time but now I think I could do it in minutes.
For DigitalOcean, one area I struggled was when I was prompted to input the path to your DigitalOcean credentials INI file. What the script is referring to is the Applications & API page and the Tokens/Key tab on that page. You need to have or generate a personal access token (read and write) for DigitalOcean's API -- this is a 65 character hexadecimal string. This string then needs to be put into a file on the webserver from which you are running certbot. That file can have a comment as its first line (comments start with #). The seccond line is:
dns_digitalocean_token = 0000111122223333444455556666777788889999aaaabbbbccccddddeeeeffff
Once I figured out how to set up a read+write token for DigitalOcean's API, it was pretty easy to use certbot to setup a wildcard certificate. Note that one does not have to setup a wildcard certificate, one may instead specify each domain and sub-domain that one wants the certificate to appply to. It was the wildcard certificate that required the credentials INI file that contained the personal access token from DigitalOcean.
Note that public key certificates (also known as identity certificates or SSL certificates) expire and require renewal. Thus you will need to renew your certificate on a periodic (reoccurring) basis. The certbot documentation covers renewing certificates.
My plan is to write a script to use the openssl command to get my certificate's expiration date and to trigger renewal when it is 30 days or less until it expires. I will then add this script to cron and run it once per day.
Here is the command to read your certificate's expiration date:
root#prod-host:~# /usr/bin/openssl x509 -enddate -noout -in path-to-certificate-pem-file
notAfter=May 25 19:24:12 2019 GMT
After much of going around, playing with various solutions, still I faced the problem that issuing a self-signed certificate for localhost, gave me error
ERR_CERT_INVALID
When expanding the details, chrome said:
You cannot visit localhost right now because the website sent
scrambled credentials...
And the only ugly way to get through is to type (directly in this screen, without seeing any cursor for the text) :
(type in the keyboard) thisisunsafe
Which let me proceed.
Until I found extendedKeyUsage = serverAuth, clientAuth
TL;DR
openssl genrsa -out localhost.key 2048
openssl req -key localhost.key -new -out localhost.csr
(click enter on everything and just fill in the common name (CN) with localhost or your other FQDN.
put the following in a file named v3.ext (edit whatever you need):
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer:always
basicConstraints = CA:TRUE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment, keyAgreement, keyCertSign
extendedKeyUsage = serverAuth, clientAuth
subjectAltName = DNS:localhost, DNS:localhost.localdomain
issuerAltName = issuer:copy
openssl x509 -req -in localhost.csr -signkey localhost.key -out localhost.pem -days 3650 -sha256 -extfile v3.ext
And voilà!
You can visit the website, expand "Advanced" and click "Proceed to localhost (unsafe)".
this worked for me
openssl req -x509 -nodes -subj '/CN=localhost' -newkey rsa:4096 -keyout ./sslcert/key.pem -out ./sslcert/cert.pem -days 365
server.js
var fs = require('fs');
var path = require('path');
var http = require('http');
var https = require('https');
var compression = require('compression');
var express = require('express');
var app = express();
app.use(compression());
app.use(express.static(__dirname + '/www'));
app.get('/*', function(req,res) {
res.sendFile(path.join(__dirname+'/www/index.html'));
});
// your express configuration here
var httpServer = http.createServer(app);
var credentials = {
key: fs.readFileSync('./sslcert/key.pem', 'utf8'),
cert: fs.readFileSync('./sslcert/cert.pem', 'utf8')
};
var httpsServer = https.createServer(credentials, app);
httpServer.listen(8080);
httpsServer.listen(8443);
console.log(`RUNNING ON http://127.0.0.1:8080`);
console.log(`RUNNING ON http://127.0.0.1:8443`);
Quick command line: Minimal Version
"I want a self signed certificate, in pfx form, for www.example.com with minimal fuss":
openssl req -x509 -sha256 -days 365 -nodes -out cert.crt -keyout cert.key -subj "/CN=www.example.com"
openssl pkcs12 -export -out cert.pfx -inkey cert.key -in cert.crt
This very simple Python app that creates a self-signed certificate.
Code:
from OpenSSL import crypto, SSL
from secrets import randbelow
print("Please know, if you make a mistake, you must restart the program.")
def cert_gen(
emailAddress=input("Enter Email Address: "),
commonName=input("Enter Common Name: "),
countryName=input("Enter Country Name (2 characters): "),
localityName=input("Enter Locality Name: "),
stateOrProvinceName=input("Enter State of Province Name: "),
organizationName=input("Enter Organization Name: "),
organizationUnitName=input("Enter Organization Unit Name: "),
serialNumber=randbelow(1000000),
validityStartInSeconds=0,
validityEndInSeconds=10*365*24*60*60,
KEY_FILE = "private.key",
CERT_FILE="selfsigned.crt"):
#can look at generated file using openssl:
#openssl x509 -inform pem -in selfsigned.crt -noout -text
# create a key pair
k = crypto.PKey()
k.generate_key(crypto.TYPE_RSA, 4096)
# create a self-signed cert
cert = crypto.X509()
cert.get_subject().C = countryName
cert.get_subject().ST = stateOrProvinceName
cert.get_subject().L = localityName
cert.get_subject().O = organizationName
cert.get_subject().OU = organizationUnitName
cert.get_subject().CN = commonName
cert.get_subject().emailAddress = emailAddress
cert.set_serial_number(serialNumber)
cert.gmtime_adj_notBefore(0)
cert.gmtime_adj_notAfter(validityEndInSeconds)
cert.set_issuer(cert.get_subject())
cert.set_pubkey(k)
cert.sign(k, 'sha512')
with open(CERT_FILE, "wt") as f:
f.write(crypto.dump_certificate(crypto.FILETYPE_PEM, cert).decode("utf-8"))
with open(KEY_FILE, "wt") as f:
f.write(crypto.dump_privatekey(crypto.FILETYPE_PEM, k).decode("utf-8"))
print("GENERATED")
input("Press enter to close program.")
cert_gen()
However, you still get the "certificate is not trusted" error. This is because of a few reasons:
It is self-signed/not verified (a verified certificate would need a CA (Certificate Authority), like Let's Encrypt to be trusted on all devices).
It is not trusted on your machine. (this answer shows how you can make Windows trust your certificate).
If you want to generate self signed certificates using open ssl - here is a script we have generated which can be used as is.
#!/bin/bash
subj='//SKIP=skip/C=IN/ST=Country/L=City/O=MyCompany/OU=Technology'
red='\033[31m' # red
yellow='\033[33m' # yellow
green='\033[32m' # green
blue='\033[34m' # Blue
purple='\033[35m' # Purple
cyan='\033[36m' # Cyan
white='\033[37m' # White
gencerts(){
certname=$1
pkname=$2
alias=$3
$(openssl genrsa -out $pkname'pem.pem' 4096)
$(openssl req -new -sha256 -key $pkname'pem.pem' -out $certname'csr.csr' -subj $subj)
$(openssl x509 -req -sha256 -days 3650 -in $certname'csr.csr' -signkey $pkname'pem.pem' -out $certname'.crt')
$(openssl pkcs12 -export -out $pkname'.p12' -name $alias -inkey $pkname'pem.pem' -in $certname'.crt')
}
verify(){
pkname=$1
keytool -v -list -storetype pkcs12 -keystore $pkname'.p12'
}
echo -e "${purple}WELCOME TO KEY PAIR GENERATOR"
echo -e "${yellow} Please enter the name of the certificate required: "
read certname
echo -e "${green}Please enter the name of the Private Key p12 file required: "
read pkname
echo -e "${cyan}Please enter the ALIAS of the Private Key p12 file : "
read pkalias
echo -e "${white}Please wait while we generate your Key Pair"
gencerts $certname $pkname $pkalias
echo -e "${white}Now lets verify the private key :)"
tput bel # Play a bell
verify $pkname
Do let me know if any improvements can be made to the script.
You don't need to use openssl's bad user interface at all! Try mkcert.
$ brew install mkcert nss
[...]
$ mkcert -install
Created a new local CA 💥
The local CA is now installed in the system trust store! ⚡️
The local CA is now installed in the Firefox trust store (requires browser restart)! 🦊
$ mkcert example.com "*.example.com" example.test localhost 127.0.0.1 ::1
Created a new certificate valid for the following names 📜
- "example.com"
- "*.example.com"
- "example.test"
- "localhost"
- "127.0.0.1"
- "::1"
The certificate is at "./example.com+5.pem" and the key at "./example.com+5-key.pem" ✅

AES128-GCM-SHA256 cipher certificate using openssl [duplicate]

Closed. This question is not about programming or software development. 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 4 months ago.
The community reviewed whether to reopen this question 3 months ago and left it closed:
Original close reason(s) were not resolved
Improve this question
I'm adding HTTPS support to an embedded Linux device. I have tried to generate a self-signed certificate with these steps:
openssl req -new > cert.csr
openssl rsa -in privkey.pem -out key.pem
openssl x509 -in cert.csr -out cert.pem -req -signkey key.pem -days 1001
cat key.pem>>cert.pem
This works, but I get some errors with, for example, Google Chrome:
This is probably not the site you are looking for!
The site's security certificate is not trusted!
Am I missing something? Is this the correct way to build a self-signed certificate?
You can do that in one command:
openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -sha256 -days 365
You can also add -nodes (short for "no DES") if you don't want to protect your private key with a passphrase. Otherwise it will prompt you for "at least a 4 character" password.
The days parameter (365) you can replace with any number to affect the expiration date. It will then prompt you for things like "Country Name", but you can just hit Enter and accept the defaults.
Add -subj '/CN=localhost' to suppress questions about the contents of the certificate (replace localhost with your desired domain).
Self-signed certificates are not validated with any third party unless you import them to the browsers previously. If you need more security, you should use a certificate signed by a certificate authority (CA).
As of 2023 with OpenSSL ≥ 1.1.1, the following command serves all your needs, including Subject Alternate Name (SAN):
openssl req -x509 -newkey rsa:4096 -sha256 -days 3650 -nodes \
-keyout example.key -out example.crt -subj "/CN=example.com" \
-addext "subjectAltName=DNS:example.com,DNS:www.example.net,IP:10.0.0.1"
On old systems with OpenSSL ≤ 1.1.0, such as Debian ≤ 9 or CentOS ≤ 7, a longer version of this command needs to be used:
openssl req -x509 -newkey rsa:4096 -sha256 -days 3650 -nodes \
-keyout example.key -out example.crt -extensions san -config \
<(echo "[req]";
echo distinguished_name=req;
echo "[san]";
echo subjectAltName=DNS:example.com,DNS:www.example.net,IP:10.0.0.1
) \
-subj "/CN=example.com"
Either command creates a certificate that is
valid for the (sub)domains example.com and www.example.net (SAN),
also valid for the IP address 10.0.0.1 (SAN),
relatively strong (as of 2023) and
valid for 3650 days (~10 years).
The following files are generated:
Private key: example.key
Certificate: example.crt
All information is provided at the command line. There is no interactive input that annoys you. There are no config files you have to mess around with. All necessary steps are executed by a single OpenSSL invocation: from private key generation up to the self-signed certificate.
Remark #1: Crypto parameters
Since the certificate is self-signed and needs to be accepted by users manually, it doesn't make sense to use a short expiration or weak cryptography.
In the future, you might want to use more than 4096 bits for the RSA key and a hash algorithm stronger than sha256, but as of 2023 these are sane values. They are sufficiently strong while being supported by all modern browsers.
Remark #2: Parameter "-nodes"
Theoretically you could leave out the -nodes parameter (which means "no DES encryption"), in which case example.key would be encrypted with a password. However, this is almost never useful for a server installation, because you would either have to store the password on the server as well, or you'd have to enter it manually on each reboot.
Remark #3: See also
Provide subjectAltName to openssl directly on command line
How to add multiple email addresses to an SSL certificate via the command line?
More information about MSYS_NO_PATHCONV
Am I missing something? Is this the correct way to build a self-signed certificate?
It's easy to create a self-signed certificate. You just use the openssl req command. It can be tricky to create one that can be consumed by the largest selection of clients, like browsers and command line tools.
It's difficult because the browsers have their own set of requirements, and they are more restrictive than the IETF. The requirements used by browsers are documented at the CA/Browser Forums (see references below). The restrictions arise in two key areas: (1) trust anchors, and (2) DNS names.
Modern browsers (like the warez we're using in 2014/2015) want a certificate that chains back to a trust anchor, and they want DNS names to be presented in particular ways in the certificate. And browsers are actively moving against self-signed server certificates.
Some browsers don't exactly make it easy to import a self-signed server certificate. In fact, you can't with some browsers, like Android's browser. So the complete solution is to become your own authority.
In the absence of becoming your own authority, you have to get the DNS names right to give the certificate the greatest chance of success. But I would encourage you to become your own authority. It's easy to become your own authority, and it will sidestep all the trust issues (who better to trust than yourself?).
This is probably not the site you are looking for!
The site's security certificate is not trusted!
This is because browsers use a predefined list of trust anchors to validate server certificates. A self-signed certificate does not chain back to a trusted anchor.
The best way to avoid this is:
Create your own authority (i.e., become a CA)
Create a certificate signing request (CSR) for the server
Sign the server's CSR with your CA key
Install the server certificate on the server
Install the CA certificate on the client
Step 1 - Create your own authority just means to create a self-signed certificate with CA: true and proper key usage. That means the Subject and Issuer are the same entity, CA is set to true in Basic Constraints (it should also be marked as critical), key usage is keyCertSign and crlSign (if you are using CRLs), and the Subject Key Identifier (SKI) is the same as the Authority Key Identifier (AKI).
To become your own certificate authority, see *How do you sign a certificate signing request with your certification authority? on Stack Overflow. Then, import your CA into the Trust Store used by the browser.
Steps 2 - 4 are roughly what you do now for a public facing server when you enlist the services of a CA like Startcom or CAcert. Steps 1 and 5 allows you to avoid the third-party authority, and act as your own authority (who better to trust than yourself?).
The next best way to avoid the browser warning is to trust the server's certificate. But some browsers, like Android's default browser, do not let you do it. So it will never work on the platform.
The issue of browsers (and other similar user agents) not trusting self-signed certificates is going to be a big problem in the Internet of Things (IoT). For example, what is going to happen when you connect to your thermostat or refrigerator to program it? The answer is, nothing good as far as the user experience is concerned.
The W3C's WebAppSec Working Group is starting to look at the issue. See, for example, Proposal: Marking HTTP As Non-Secure.
How to create a self-signed certificate with OpenSSL
The commands below and the configuration file create a self-signed certificate (it also shows you how to create a signing request). They differ from other answers in one respect: the DNS names used for the self signed certificate are in the Subject Alternate Name (SAN), and not the Common Name (CN).
The DNS names are placed in the SAN through the configuration file with the line subjectAltName = #alternate_names (there's no way to do it through the command line). Then there's an alternate_names section in the configuration file (you should tune this to suit your taste):
[ alternate_names ]
DNS.1 = example.com
DNS.2 = www.example.com
DNS.3 = mail.example.com
DNS.4 = ftp.example.com
# Add these if you need them. But usually you don't want them or
# need them in production. You may need them for development.
# DNS.5 = localhost
# DNS.6 = localhost.localdomain
# IP.1 = 127.0.0.1
# IP.2 = ::1
It's important to put DNS name in the SAN and not the CN, because both the IETF and the CA/Browser Forums specify the practice. They also specify that DNS names in the CN are deprecated (but not prohibited). If you put a DNS name in the CN, then it must be included in the SAN under the CA/B policies. So you can't avoid using the Subject Alternate Name.
If you don't do put DNS names in the SAN, then the certificate will fail to validate under a browser and other user agents which follow the CA/Browser Forum guidelines.
Related: browsers follow the CA/Browser Forum policies; and not the IETF policies. That's one of the reasons a certificate created with OpenSSL (which generally follows the IETF) sometimes does not validate under a browser (browsers follow the CA/B). They are different standards, they have different issuing policies and different validation requirements.
Create a self signed certificate (notice the addition of -x509 option):
openssl req -config example-com.conf -new -x509 -sha256 -newkey rsa:2048 -nodes \
-keyout example-com.key.pem -days 365 -out example-com.cert.pem
Create a signing request (notice the lack of -x509 option):
openssl req -config example-com.conf -new -sha256 -newkey rsa:2048 -nodes \
-keyout example-com.key.pem -days 365 -out example-com.req.pem
Print a self-signed certificate:
openssl x509 -in example-com.cert.pem -text -noout
Print a signing request:
openssl req -in example-com.req.pem -text -noout
Configuration file (passed via -config option)
[ req ]
default_bits = 2048
default_keyfile = server-key.pem
distinguished_name = subject
req_extensions = req_ext
x509_extensions = x509_ext
string_mask = utf8only
# The Subject DN can be formed using X501 or RFC 4514 (see RFC 4519 for a description).
# Its sort of a mashup. For example, RFC 4514 does not provide emailAddress.
[ subject ]
countryName = Country Name (2 letter code)
countryName_default = US
stateOrProvinceName = State or Province Name (full name)
stateOrProvinceName_default = NY
localityName = Locality Name (eg, city)
localityName_default = New York
organizationName = Organization Name (eg, company)
organizationName_default = Example, LLC
# Use a friendly name here because it's presented to the user. The server's DNS
# names are placed in Subject Alternate Names. Plus, DNS names here is deprecated
# by both IETF and CA/Browser Forums. If you place a DNS name here, then you
# must include the DNS name in the SAN too (otherwise, Chrome and others that
# strictly follow the CA/Browser Baseline Requirements will fail).
commonName = Common Name (e.g. server FQDN or YOUR name)
commonName_default = Example Company
emailAddress = Email Address
emailAddress_default = test#example.com
# Section x509_ext is used when generating a self-signed certificate. I.e., openssl req -x509 ...
[ x509_ext ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
# You only need digitalSignature below. *If* you don't allow
# RSA Key transport (i.e., you use ephemeral cipher suites), then
# omit keyEncipherment because that's key transport.
basicConstraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment
subjectAltName = #alternate_names
nsComment = "OpenSSL Generated Certificate"
# RFC 5280, Section 4.2.1.12 makes EKU optional
# CA/Browser Baseline Requirements, Appendix (B)(3)(G) makes me confused
# In either case, you probably only need serverAuth.
# extendedKeyUsage = serverAuth, clientAuth
# Section req_ext is used when generating a certificate signing request. I.e., openssl req ...
[ req_ext ]
subjectKeyIdentifier = hash
basicConstraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment
subjectAltName = #alternate_names
nsComment = "OpenSSL Generated Certificate"
# RFC 5280, Section 4.2.1.12 makes EKU optional
# CA/Browser Baseline Requirements, Appendix (B)(3)(G) makes me confused
# In either case, you probably only need serverAuth.
# extendedKeyUsage = serverAuth, clientAuth
[ alternate_names ]
DNS.1 = example.com
DNS.2 = www.example.com
DNS.3 = mail.example.com
DNS.4 = ftp.example.com
# Add these if you need them. But usually you don't want them or
# need them in production. You may need them for development.
# DNS.5 = localhost
# DNS.6 = localhost.localdomain
# DNS.7 = 127.0.0.1
# IPv6 localhost
# DNS.8 = ::1
You may need to do the following for Chrome. Otherwise Chrome may complain a Common Name is invalid (ERR_CERT_COMMON_NAME_INVALID). I'm not sure what the relationship is between an IP address in the SAN and a CN in this instance.
# IPv4 localhost
# IP.1 = 127.0.0.1
# IPv6 localhost
# IP.2 = ::1
There are other rules concerning the handling of DNS names in X.509/PKIX certificates. Refer to these documents for the rules:
RFC 5280, Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
RFC 6125, Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)
RFC 6797, Appendix A, HTTP Strict Transport Security (HSTS)
RFC 7469, Public Key Pinning Extension for HTTP
CA/Browser Forum Baseline Requirements
CA/Browser Forum Extended Validation Guidelines
RFC 6797 and RFC 7469 are listed, because they are more restrictive than the other RFCs and CA/B documents. RFCs 6797 and 7469 do not allow an IP address, either.
Here are the options described in #diegows's answer, described in more detail, from the documentation:
openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days XXX
req
PKCS#10 certificate request and certificate generating utility.
-x509
this option outputs a self signed certificate instead of a certificate request.
This is typically used to generate a test certificate or a self signed root CA.
-newkey arg
this option creates a new certificate request and a new private key. The argument
takes one of several forms. rsa:nbits, where nbits is the number of bits,
generates an RSA key nbits in size.
-keyout filename
this gives the filename to write the newly created private key to.
-out filename
This specifies the output filename to write to or standard output by default.
-days n
when the -x509 option is being used this specifies the number of days to certify
the certificate for. The default is 30 days.
-nodes
if this option is specified then if a private key is created it will not be encrypted.
The documentation is actually more detailed than the above; I just summarized it here.
I can't comment, so I will put this as a separate answer. I found a few issues with the accepted one-liner answer:
The one-liner includes a passphrase in the key.
The one-liner uses SHA-1 which in many browsers throws warnings in console.
Here is a simplified version that removes the passphrase, ups the security to suppress warnings and includes a suggestion in comments to pass in -subj to remove the full question list:
openssl genrsa -out server.key 2048
openssl rsa -in server.key -out server.key
openssl req -sha256 -new -key server.key -out server.csr -subj '/CN=localhost'
openssl x509 -req -sha256 -days 365 -in server.csr -signkey server.key -out server.crt
Replace 'localhost' with whatever domain you require. You will need to run the first two commands one by one as OpenSSL will prompt for a passphrase.
To combine the two into a .pem file:
cat server.crt server.key > cert.pem
Modern browsers now throw a security error for otherwise well-formed self-signed certificates if they are missing a SAN (Subject Alternate Name). OpenSSL does not provide a command-line way to specify this, so many developers' tutorials and bookmarks are suddenly outdated.
The quickest way to get running again is a short, stand-alone conf file:
Create an OpenSSL config file (example: req.cnf)
[req]
distinguished_name = req_distinguished_name
x509_extensions = v3_req
prompt = no
[req_distinguished_name]
C = US
ST = VA
L = SomeCity
O = MyCompany
OU = MyDivision
CN = www.company.com
[v3_req]
keyUsage = critical, digitalSignature, keyAgreement
extendedKeyUsage = serverAuth
subjectAltName = #alt_names
[alt_names]
DNS.1 = www.company.com
DNS.2 = company.com
DNS.3 = company.net
Create the certificate referencing this config file
openssl req -x509 -nodes -days 730 -newkey rsa:2048 \
-keyout cert.key -out cert.pem -config req.cnf -sha256
Example config from https://support.citrix.com/article/CTX135602
I would recommend to add the -sha256 parameter, to use the SHA-2 hash algorithm, because major browsers are considering to show "SHA-1 certificates" as not secure.
The same command line from the accepted answer - #diegows with added -sha256
openssl req -x509 -sha256 -newkey rsa:2048 -keyout key.pem -out cert.pem -days XXX
More information in Google Security blog.
Update May 2018. As many noted in the comments that using SHA-2 does not add any security to a self-signed certificate. But I still recommend using it as a good habit of not using outdated / insecure cryptographic hash functions. Full explanation is available in Why is it fine for certificates above the end-entity certificate to be SHA-1 based?.
I can`t comment so I add a separate answer.
I tried to create a self-signed certificate for NGINX and it was easy, but when I wanted to add it to Chrome white list I had a problem. And my solution was to create a Root certificate and signed a child certificate by it.
So step by step.
Create file config_ssl_ca.cnf
Notice, config file has an option basicConstraints=CA:true which means that this certificate is supposed to be root.
This is a good practice, because you create it once and can reuse.
[ req ]
default_bits = 2048
prompt = no
distinguished_name=req_distinguished_name
req_extensions = v3_req
[ req_distinguished_name ]
countryName=UA
stateOrProvinceName=root region
localityName=root city
organizationName=Market(localhost)
organizationalUnitName=roote department
commonName=market.localhost
emailAddress=root_email#root.localhost
[ alternate_names ]
DNS.1 = market.localhost
DNS.2 = www.market.localhost
DNS.3 = mail.market.localhost
DNS.4 = ftp.market.localhost
DNS.5 = *.market.localhost
[ v3_req ]
keyUsage=digitalSignature
basicConstraints=CA:true
subjectKeyIdentifier = hash
subjectAltName = #alternate_names
Next config file for your child certificate will be call config_ssl.cnf.
[ req ]
default_bits = 2048
prompt = no
distinguished_name=req_distinguished_name
req_extensions = v3_req
[ req_distinguished_name ]
countryName=UA
stateOrProvinceName=Kyiv region
localityName=Kyiv
organizationName=market place
organizationalUnitName=market place department
commonName=market.localhost
emailAddress=email#market.localhost
[ alternate_names ]
DNS.1 = market.localhost
DNS.2 = www.market.localhost
DNS.3 = mail.market.localhost
DNS.4 = ftp.market.localhost
DNS.5 = *.market.localhost
[ v3_req ]
keyUsage=digitalSignature
basicConstraints=CA:false
subjectAltName = #alternate_names
subjectKeyIdentifier = hash
The first step - create Root key and certificate
openssl genrsa -out ca.key 2048
openssl req -new -x509 -key ca.key -out ca.crt -days 365 -config config_ssl_ca.cnf
The second step creates child key and file CSR - Certificate Signing Request. Because the idea is to sign the child certificate by root and get a correct certificate
openssl genrsa -out market.key 2048
openssl req -new -sha256 -key market.key -config config_ssl.cnf -out market.csr
Open Linux terminal and do this command
echo 00 > ca.srl
touch index.txt
The ca.srl text file containing the next serial number to use in hex.
Mandatory. This file must be present and contain a valid serial number.
Last Step, create one more config file and call it config_ca.cnf
# we use 'ca' as the default section because we're usign the ca command
[ ca ]
default_ca = my_ca
[ my_ca ]
# a text file containing the next serial number to use in hex. Mandatory.
# This file must be present and contain a valid serial number.
serial = ./ca.srl
# the text database file to use. Mandatory. This file must be present though
# initially it will be empty.
database = ./index.txt
# specifies the directory where new certificates will be placed. Mandatory.
new_certs_dir = ./
# the file containing the CA certificate. Mandatory
certificate = ./ca.crt
# the file contaning the CA private key. Mandatory
private_key = ./ca.key
# the message digest algorithm. Remember to not use MD5
default_md = sha256
# for how many days will the signed certificate be valid
default_days = 365
# a section with a set of variables corresponding to DN fields
policy = my_policy
# MOST IMPORTANT PART OF THIS CONFIG
copy_extensions = copy
[ my_policy ]
# if the value is "match" then the field value must match the same field in the
# CA certificate. If the value is "supplied" then it must be present.
# Optional means it may be present. Any fields not mentioned are silently
# deleted.
countryName = match
stateOrProvinceName = supplied
organizationName = supplied
commonName = market.localhost
organizationalUnitName = optional
commonName = supplied
You may ask, why so difficult, why we must create one more config to sign child certificate by root. The answer is simple because child certificate must have a SAN block - Subject Alternative Names.
If we sign the child certificate by "openssl x509" utils, the Root certificate will delete the SAN field in child certificate.
So we use "openssl ca" instead of "openssl x509" to avoid the deleting of the SAN field. We create a new config file and tell it to copy all extended fields copy_extensions = copy.
openssl ca -config config_ca.cnf -out market.crt -in market.csr
The program asks you 2 questions:
Sign the certificate? Say "Y"
1 out of 1 certificate requests certified, commit? Say "Y"
In terminal you can see a sentence with the word "Database", it means file index.txt which you create by the command "touch". It will contain all information by all certificates you create by "openssl ca" util.
To check the certificate valid use:
openssl rsa -in market.key -check
If you want to see what inside in CRT:
openssl x509 -in market.crt -text -noout
If you want to see what inside in CSR:
openssl req -in market.csr -noout -text
This is the script I use on local boxes to set the SAN (subjectAltName) in self-signed certificates.
This script takes the domain name (example.com) and generates the SAN for *.example.com and example.com in the same certificate. The sections below are commented. Name the script (e.g. generate-ssl.sh) and give it executable permissions. The files will be written to the same directory as the script.
Chrome 58 an onward requires SAN to be set in self-signed certificates.
#!/usr/bin/env bash
# Set the TLD domain we want to use
BASE_DOMAIN="example.com"
# Days for the cert to live
DAYS=1095
# A blank passphrase
PASSPHRASE=""
# Generated configuration file
CONFIG_FILE="config.txt"
cat > $CONFIG_FILE <<-EOF
[req]
default_bits = 2048
prompt = no
default_md = sha256
x509_extensions = v3_req
distinguished_name = dn
[dn]
C = CA
ST = BC
L = Vancouver
O = Example Corp
OU = Testing Domain
emailAddress = webmaster#$BASE_DOMAIN
CN = $BASE_DOMAIN
[v3_req]
subjectAltName = #alt_names
[alt_names]
DNS.1 = *.$BASE_DOMAIN
DNS.2 = $BASE_DOMAIN
EOF
# The file name can be anything
FILE_NAME="$BASE_DOMAIN"
# Remove previous keys
echo "Removing existing certs like $FILE_NAME.*"
chmod 770 $FILE_NAME.*
rm $FILE_NAME.*
echo "Generating certs for $BASE_DOMAIN"
# Generate our Private Key, CSR and Certificate
# Use SHA-2 as SHA-1 is unsupported from Jan 1, 2017
openssl req -new -x509 -newkey rsa:2048 -sha256 -nodes -keyout "$FILE_NAME.key" -days $DAYS -out "$FILE_NAME.crt" -passin pass:$PASSPHRASE -config "$CONFIG_FILE"
# OPTIONAL - write an info to see the details of the generated crt
openssl x509 -noout -fingerprint -text < "$FILE_NAME.crt" > "$FILE_NAME.info"
# Protect the key
chmod 400 "$FILE_NAME.key"
This script also writes an information file, so you can inspect the new certificate and verify the SAN is set properly.
...
28:dd:b8:1e:34:b5:b1:44:1a:60:6d:e3:3c:5a:c4:
da:3d
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Alternative Name:
DNS:*.example.com, DNS:example.com
Signature Algorithm: sha256WithRSAEncryption
3b:35:5a:d6:9e:92:4f:fc:f4:f4:87:78:cd:c7:8d:cd:8c:cc:
...
If you are using Apache, then you can reference the above certificate in your configuration file like so:
<VirtualHost _default_:443>
ServerName example.com
ServerAlias www.example.com
DocumentRoot /var/www/htdocs
SSLEngine on
SSLCertificateFile path/to/your/example.com.crt
SSLCertificateKeyFile path/to/your/example.com.key
</VirtualHost>
Remember to restart your Apache (or Nginx, or IIS) server for the new certificate to take effect.
2017 one-liner:
openssl req \
-newkey rsa:2048 \
-x509 \
-nodes \
-keyout server.pem \
-new \
-out server.pem \
-subj /CN=localhost \
-reqexts SAN \
-extensions SAN \
-config <(cat /System/Library/OpenSSL/openssl.cnf \
<(printf '[SAN]\nsubjectAltName=DNS:localhost')) \
-sha256 \
-days 3650
This also works in Chrome 57, as it provides the SAN, without having another configuration file.
It was taken from an answer here.
This creates a single .pem file that contains both the private key and cert. You can move them to separate .pem files if needed.
Generate a key without password and certificate for 10 years, the short way:
openssl req -x509 -nodes -new -keyout server.key -out server.crt -days 3650 -subj "/C=/ST=/L=/O=/OU=web/CN=www.server.com"
for the flag -subj | -subject empty values are permitted -subj "/C=/ST=/L=/O=/OU=web/CN=www.server.com", but you can sets more details as you like:
C - Country Name (2 letter code)
ST - State
L - Locality Name (eg, city)
O - Organization Name
OU - Organizational Unit Name
CN - Common Name - required!
One-liner version 2017:
CentOS:
openssl req -x509 -nodes -sha256 -newkey rsa:2048 \
-keyout localhost.key -out localhost.crt \
-days 3650 \
-subj "CN=localhost" \
-reqexts SAN -extensions SAN \
-config <(cat /etc/pki/tls/openssl.cnf <(printf "\n[SAN]\nsubjectAltName=IP:127.0.0.1,DNS:localhost"))
Ubuntu:
openssl req -x509 -nodes -sha256 -newkey rsa:2048 \
-keyout localhost.key -out localhost.crt \
-days 3650 \
-subj "/CN=localhost" \
-reqexts SAN -extensions SAN \
-config <(cat /etc/ssl/openssl.cnf <(printf "\n[SAN]\nsubjectAltName=IP:127.0.0.1,DNS:localhost"))
Edit: added prepending Slash to 'subj' option for Ubuntu.
openssl allows to generate self-signed certificate by a single command (-newkey
instructs to generate a private key and -x509 instructs to issue a self-signed
certificate instead of a signing request)::
openssl req -x509 -newkey rsa:4096 \
-keyout my.key -passout pass:123456 -out my.crt \
-days 365 \
-subj /CN=localhost/O=home/C=US/emailAddress=me#mail.internal \
-addext "subjectAltName = DNS:localhost,DNS:web.internal,email:me#mail.internal" \
-addext keyUsage=digitalSignature -addext extendedKeyUsage=serverAuth
You can generate a private key and construct a self-signing certificate in separate steps::
openssl genrsa -out my.key -passout pass:123456 2048
openssl req -x509 \
-key my.key -passin pass:123456 -out my.csr \
-days 3650 \
-subj /CN=localhost/O=home/C=US/emailAddress=me#mail.internal \
-addext "subjectAltName = DNS:localhost,DNS:web.internal,email:me#mail.internal" \
-addext keyUsage=digitalSignature -addext extendedKeyUsage=serverAuth
Review the resulting certificate::
openssl x509 -text -noout -in my.crt
Java keytool creates PKCS#12 store::
keytool -genkeypair -keystore my.p12 -alias master \
-storetype pkcs12 -keyalg RSA -keysize 2048 -validity 3650 \
-storepass 123456 \
-dname "CN=localhost,O=home,C=US" \
-ext 'san=dns:localhost,dns:web.internal,email:me#mail.internal'
To export the self-signed certificate::
keytool -exportcert -keystore my.p12 -file my.crt \
-alias master -rfc -storepass 123456
Review the resulting certificate::
keytool -printcert -file my.crt
certtool from GnuTLS doesn't allow passing different attributes from CLI. I don't like to mess with config files ((
Generate keys
I am using /etc/mysql for cert storage because /etc/apparmor.d/usr.sbin.mysqld contains /etc/mysql/*.pem r.
sudo su -
cd /etc/mysql
openssl genrsa -out ca-key.pem 2048;
openssl req -new -x509 -nodes -days 1000 -key ca-key.pem -out ca-cert.pem;
openssl req -newkey rsa:2048 -days 1000 -nodes -keyout server-key.pem -out server-req.pem;
openssl x509 -req -in server-req.pem -days 1000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 -out server-cert.pem;
openssl req -newkey rsa:2048 -days 1000 -nodes -keyout client-key.pem -out client-req.pem;
openssl x509 -req -in client-req.pem -days 1000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 -out client-cert.pem;
Add configuration
/etc/mysql/my.cnf
[client]
ssl-ca=/etc/mysql/ca-cert.pem
ssl-cert=/etc/mysql/client-cert.pem
ssl-key=/etc/mysql/client-key.pem
[mysqld]
ssl-ca=/etc/mysql/ca-cert.pem
ssl-cert=/etc/mysql/server-cert.pem
ssl-key=/etc/mysql/server-key.pem
On my setup, Ubuntu server logged to: /var/log/mysql/error.log
Follow up notes:
SSL error: Unable to get certificate from '...'
MySQL might be denied read access to your certificate file if it is not in apparmors configuration. As mentioned in the previous steps^, save all our certificates as .pem files in the /etc/mysql/ directory which is approved by default by apparmor (or modify your apparmor/SELinux to allow access to wherever you stored them.)
SSL error: Unable to get private key
Your MySQL server version may not support the default rsa:2048 format
Convert generated rsa:2048 to plain rsa with:
openssl rsa -in server-key.pem -out server-key.pem
openssl rsa -in client-key.pem -out client-key.pem
Check if local server supports SSL:
mysql -u root -p
mysql> show variables like "%ssl%";
+---------------+----------------------------+
| Variable_name | Value |
+---------------+----------------------------+
| have_openssl | YES |
| have_ssl | YES |
| ssl_ca | /etc/mysql/ca-cert.pem |
| ssl_capath | |
| ssl_cert | /etc/mysql/server-cert.pem |
| ssl_cipher | |
| ssl_key | /etc/mysql/server-key.pem |
+---------------+----------------------------+
Verifying a connection to the database is SSL encrypted:
Verifying connection
When logged in to the MySQL instance, you can issue the query:
show status like 'Ssl_cipher';
If your connection is not encrypted, the result will be blank:
mysql> show status like 'Ssl_cipher';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Ssl_cipher | |
+---------------+-------+
1 row in set (0.00 sec)
Otherwise, it would show a non-zero length string for the cypher in use:
mysql> show status like 'Ssl_cipher';
+---------------+--------------------+
| Variable_name | Value |
+---------------+--------------------+
| Ssl_cipher | DHE-RSA-AES256-SHA |
+---------------+--------------------+
1 row in set (0.00 sec)
Require ssl for specific user's connection ('require ssl'):
SSL
Tells the server to permit only SSL-encrypted connections for the account.
GRANT ALL PRIVILEGES ON test.* TO 'root'#'localhost'
REQUIRE SSL;
To connect, the client must specify the --ssl-ca option to authenticate the server certificate, and may additionally specify the --ssl-key and --ssl-cert options. If neither --ssl-ca option nor --ssl-capath option is specified, the client does not authenticate the server certificate.
Alternate link: Lengthy tutorial in Secure PHP Connections to MySQL with SSL.
One liner FTW. I like to keep it simple. Why not use one command that contains ALL the arguments needed? This is how I like it - this creates an x509 certificate and its PEM key:
openssl req -x509 \
-nodes -days 365 -newkey rsa:4096 \
-keyout self.key.pem \
-out self-x509.crt \
-subj "/C=US/ST=WA/L=Seattle/CN=example.com/emailAddress=someEmail#gmail.com"
That single command contains all the answers you would normally provide for the certificate details. This way you can set the parameters and run the command, get your output - then go for coffee.
>> More here <<
You have the general procedure correct. The syntax for the command is below.
openssl req -new -key {private key file} -out {output file}
However, the warnings are displayed, because the browser was not able to verify the identify by validating the certificate with a known Certificate Authority (CA).
As this is a self-signed certificate there is no CA and you can safely ignore the warning and proceed. Should you want to get a real certificate that will be recognizable by anyone on the public Internet then the procedure is below.
Generate a private key
Use that private key to create a CSR file
Submit CSR to CA (Verisign or others, etc.)
Install received cert from CA on web server
Add other certs to authentication chain depending on the type cert
I have more details about this in a post at Securing the Connection: Creating a Security Certificate with OpenSSL
As has been discussed in detail, self-signed certificates are not trusted for the Internet. You can add your self-signed certificate to many but not all browsers. Alternatively you can become your own certificate authority.
The primary reason one does not want to get a signed certificate from a certificate authority is cost -- Symantec charges between $995 - $1,999 per year for certificates -- just for a certificate intended for internal network, Symantec charges $399 per year. That cost is easy to justify if you are processing credit card payments or work for the profit center of a highly profitable company. It is more than many can afford for a personal project one is creating on the internet, or for a non-profit running on a minimal budget, or if one works in a cost center of an organization -- cost centers always try to do more with less.
An alternative is to use certbot (see about certbot). Certbot is an easy-to-use automatic client that fetches and deploys SSL/TLS certificates for your web server.
If you setup certbot, you can enable it to create and maintain a certificate for you issued by the Let’s Encrypt certificate authority.
I did this over the weekend for my organization. I installed the required packages for certbot on my server (Ubuntu 16.04) and then ran the command necessary to setup and enable certbot. One likely needs a DNS plugin for certbot - we are presently using DigitalOcean though may be migrating to another service soon.
Note that some of the instructions were not quite right and took a little poking and time with Google to figure out. This took a fair amount of my time the first time but now I think I could do it in minutes.
For DigitalOcean, one area I struggled was when I was prompted to input the path to your DigitalOcean credentials INI file. What the script is referring to is the Applications & API page and the Tokens/Key tab on that page. You need to have or generate a personal access token (read and write) for DigitalOcean's API -- this is a 65 character hexadecimal string. This string then needs to be put into a file on the webserver from which you are running certbot. That file can have a comment as its first line (comments start with #). The seccond line is:
dns_digitalocean_token = 0000111122223333444455556666777788889999aaaabbbbccccddddeeeeffff
Once I figured out how to set up a read+write token for DigitalOcean's API, it was pretty easy to use certbot to setup a wildcard certificate. Note that one does not have to setup a wildcard certificate, one may instead specify each domain and sub-domain that one wants the certificate to appply to. It was the wildcard certificate that required the credentials INI file that contained the personal access token from DigitalOcean.
Note that public key certificates (also known as identity certificates or SSL certificates) expire and require renewal. Thus you will need to renew your certificate on a periodic (reoccurring) basis. The certbot documentation covers renewing certificates.
My plan is to write a script to use the openssl command to get my certificate's expiration date and to trigger renewal when it is 30 days or less until it expires. I will then add this script to cron and run it once per day.
Here is the command to read your certificate's expiration date:
root#prod-host:~# /usr/bin/openssl x509 -enddate -noout -in path-to-certificate-pem-file
notAfter=May 25 19:24:12 2019 GMT
After much of going around, playing with various solutions, still I faced the problem that issuing a self-signed certificate for localhost, gave me error
ERR_CERT_INVALID
When expanding the details, chrome said:
You cannot visit localhost right now because the website sent
scrambled credentials...
And the only ugly way to get through is to type (directly in this screen, without seeing any cursor for the text) :
(type in the keyboard) thisisunsafe
Which let me proceed.
Until I found extendedKeyUsage = serverAuth, clientAuth
TL;DR
openssl genrsa -out localhost.key 2048
openssl req -key localhost.key -new -out localhost.csr
(click enter on everything and just fill in the common name (CN) with localhost or your other FQDN.
put the following in a file named v3.ext (edit whatever you need):
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer:always
basicConstraints = CA:TRUE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment, keyAgreement, keyCertSign
extendedKeyUsage = serverAuth, clientAuth
subjectAltName = DNS:localhost, DNS:localhost.localdomain
issuerAltName = issuer:copy
openssl x509 -req -in localhost.csr -signkey localhost.key -out localhost.pem -days 3650 -sha256 -extfile v3.ext
And voilà!
You can visit the website, expand "Advanced" and click "Proceed to localhost (unsafe)".
this worked for me
openssl req -x509 -nodes -subj '/CN=localhost' -newkey rsa:4096 -keyout ./sslcert/key.pem -out ./sslcert/cert.pem -days 365
server.js
var fs = require('fs');
var path = require('path');
var http = require('http');
var https = require('https');
var compression = require('compression');
var express = require('express');
var app = express();
app.use(compression());
app.use(express.static(__dirname + '/www'));
app.get('/*', function(req,res) {
res.sendFile(path.join(__dirname+'/www/index.html'));
});
// your express configuration here
var httpServer = http.createServer(app);
var credentials = {
key: fs.readFileSync('./sslcert/key.pem', 'utf8'),
cert: fs.readFileSync('./sslcert/cert.pem', 'utf8')
};
var httpsServer = https.createServer(credentials, app);
httpServer.listen(8080);
httpsServer.listen(8443);
console.log(`RUNNING ON http://127.0.0.1:8080`);
console.log(`RUNNING ON http://127.0.0.1:8443`);
Quick command line: Minimal Version
"I want a self signed certificate, in pfx form, for www.example.com with minimal fuss":
openssl req -x509 -sha256 -days 365 -nodes -out cert.crt -keyout cert.key -subj "/CN=www.example.com"
openssl pkcs12 -export -out cert.pfx -inkey cert.key -in cert.crt
This very simple Python app that creates a self-signed certificate.
Code:
from OpenSSL import crypto, SSL
from secrets import randbelow
print("Please know, if you make a mistake, you must restart the program.")
def cert_gen(
emailAddress=input("Enter Email Address: "),
commonName=input("Enter Common Name: "),
countryName=input("Enter Country Name (2 characters): "),
localityName=input("Enter Locality Name: "),
stateOrProvinceName=input("Enter State of Province Name: "),
organizationName=input("Enter Organization Name: "),
organizationUnitName=input("Enter Organization Unit Name: "),
serialNumber=randbelow(1000000),
validityStartInSeconds=0,
validityEndInSeconds=10*365*24*60*60,
KEY_FILE = "private.key",
CERT_FILE="selfsigned.crt"):
#can look at generated file using openssl:
#openssl x509 -inform pem -in selfsigned.crt -noout -text
# create a key pair
k = crypto.PKey()
k.generate_key(crypto.TYPE_RSA, 4096)
# create a self-signed cert
cert = crypto.X509()
cert.get_subject().C = countryName
cert.get_subject().ST = stateOrProvinceName
cert.get_subject().L = localityName
cert.get_subject().O = organizationName
cert.get_subject().OU = organizationUnitName
cert.get_subject().CN = commonName
cert.get_subject().emailAddress = emailAddress
cert.set_serial_number(serialNumber)
cert.gmtime_adj_notBefore(0)
cert.gmtime_adj_notAfter(validityEndInSeconds)
cert.set_issuer(cert.get_subject())
cert.set_pubkey(k)
cert.sign(k, 'sha512')
with open(CERT_FILE, "wt") as f:
f.write(crypto.dump_certificate(crypto.FILETYPE_PEM, cert).decode("utf-8"))
with open(KEY_FILE, "wt") as f:
f.write(crypto.dump_privatekey(crypto.FILETYPE_PEM, k).decode("utf-8"))
print("GENERATED")
input("Press enter to close program.")
cert_gen()
However, you still get the "certificate is not trusted" error. This is because of a few reasons:
It is self-signed/not verified (a verified certificate would need a CA (Certificate Authority), like Let's Encrypt to be trusted on all devices).
It is not trusted on your machine. (this answer shows how you can make Windows trust your certificate).
If you want to generate self signed certificates using open ssl - here is a script we have generated which can be used as is.
#!/bin/bash
subj='//SKIP=skip/C=IN/ST=Country/L=City/O=MyCompany/OU=Technology'
red='\033[31m' # red
yellow='\033[33m' # yellow
green='\033[32m' # green
blue='\033[34m' # Blue
purple='\033[35m' # Purple
cyan='\033[36m' # Cyan
white='\033[37m' # White
gencerts(){
certname=$1
pkname=$2
alias=$3
$(openssl genrsa -out $pkname'pem.pem' 4096)
$(openssl req -new -sha256 -key $pkname'pem.pem' -out $certname'csr.csr' -subj $subj)
$(openssl x509 -req -sha256 -days 3650 -in $certname'csr.csr' -signkey $pkname'pem.pem' -out $certname'.crt')
$(openssl pkcs12 -export -out $pkname'.p12' -name $alias -inkey $pkname'pem.pem' -in $certname'.crt')
}
verify(){
pkname=$1
keytool -v -list -storetype pkcs12 -keystore $pkname'.p12'
}
echo -e "${purple}WELCOME TO KEY PAIR GENERATOR"
echo -e "${yellow} Please enter the name of the certificate required: "
read certname
echo -e "${green}Please enter the name of the Private Key p12 file required: "
read pkname
echo -e "${cyan}Please enter the ALIAS of the Private Key p12 file : "
read pkalias
echo -e "${white}Please wait while we generate your Key Pair"
gencerts $certname $pkname $pkalias
echo -e "${white}Now lets verify the private key :)"
tput bel # Play a bell
verify $pkname
Do let me know if any improvements can be made to the script.
You don't need to use openssl's bad user interface at all! Try mkcert.
$ brew install mkcert nss
[...]
$ mkcert -install
Created a new local CA 💥
The local CA is now installed in the system trust store! ⚡️
The local CA is now installed in the Firefox trust store (requires browser restart)! 🦊
$ mkcert example.com "*.example.com" example.test localhost 127.0.0.1 ::1
Created a new certificate valid for the following names 📜
- "example.com"
- "*.example.com"
- "example.test"
- "localhost"
- "127.0.0.1"
- "::1"
The certificate is at "./example.com+5.pem" and the key at "./example.com+5-key.pem" ✅

How to generate a self-signed SSL certificate using OpenSSL? [closed]

Closed. This question is not about programming or software development. 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 4 months ago.
The community reviewed whether to reopen this question 3 months ago and left it closed:
Original close reason(s) were not resolved
Improve this question
I'm adding HTTPS support to an embedded Linux device. I have tried to generate a self-signed certificate with these steps:
openssl req -new > cert.csr
openssl rsa -in privkey.pem -out key.pem
openssl x509 -in cert.csr -out cert.pem -req -signkey key.pem -days 1001
cat key.pem>>cert.pem
This works, but I get some errors with, for example, Google Chrome:
This is probably not the site you are looking for!
The site's security certificate is not trusted!
Am I missing something? Is this the correct way to build a self-signed certificate?
You can do that in one command:
openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -sha256 -days 365
You can also add -nodes (short for "no DES") if you don't want to protect your private key with a passphrase. Otherwise it will prompt you for "at least a 4 character" password.
The days parameter (365) you can replace with any number to affect the expiration date. It will then prompt you for things like "Country Name", but you can just hit Enter and accept the defaults.
Add -subj '/CN=localhost' to suppress questions about the contents of the certificate (replace localhost with your desired domain).
Self-signed certificates are not validated with any third party unless you import them to the browsers previously. If you need more security, you should use a certificate signed by a certificate authority (CA).
As of 2023 with OpenSSL ≥ 1.1.1, the following command serves all your needs, including Subject Alternate Name (SAN):
openssl req -x509 -newkey rsa:4096 -sha256 -days 3650 -nodes \
-keyout example.key -out example.crt -subj "/CN=example.com" \
-addext "subjectAltName=DNS:example.com,DNS:www.example.net,IP:10.0.0.1"
On old systems with OpenSSL ≤ 1.1.0, such as Debian ≤ 9 or CentOS ≤ 7, a longer version of this command needs to be used:
openssl req -x509 -newkey rsa:4096 -sha256 -days 3650 -nodes \
-keyout example.key -out example.crt -extensions san -config \
<(echo "[req]";
echo distinguished_name=req;
echo "[san]";
echo subjectAltName=DNS:example.com,DNS:www.example.net,IP:10.0.0.1
) \
-subj "/CN=example.com"
Either command creates a certificate that is
valid for the (sub)domains example.com and www.example.net (SAN),
also valid for the IP address 10.0.0.1 (SAN),
relatively strong (as of 2023) and
valid for 3650 days (~10 years).
The following files are generated:
Private key: example.key
Certificate: example.crt
All information is provided at the command line. There is no interactive input that annoys you. There are no config files you have to mess around with. All necessary steps are executed by a single OpenSSL invocation: from private key generation up to the self-signed certificate.
Remark #1: Crypto parameters
Since the certificate is self-signed and needs to be accepted by users manually, it doesn't make sense to use a short expiration or weak cryptography.
In the future, you might want to use more than 4096 bits for the RSA key and a hash algorithm stronger than sha256, but as of 2023 these are sane values. They are sufficiently strong while being supported by all modern browsers.
Remark #2: Parameter "-nodes"
Theoretically you could leave out the -nodes parameter (which means "no DES encryption"), in which case example.key would be encrypted with a password. However, this is almost never useful for a server installation, because you would either have to store the password on the server as well, or you'd have to enter it manually on each reboot.
Remark #3: See also
Provide subjectAltName to openssl directly on command line
How to add multiple email addresses to an SSL certificate via the command line?
More information about MSYS_NO_PATHCONV
Am I missing something? Is this the correct way to build a self-signed certificate?
It's easy to create a self-signed certificate. You just use the openssl req command. It can be tricky to create one that can be consumed by the largest selection of clients, like browsers and command line tools.
It's difficult because the browsers have their own set of requirements, and they are more restrictive than the IETF. The requirements used by browsers are documented at the CA/Browser Forums (see references below). The restrictions arise in two key areas: (1) trust anchors, and (2) DNS names.
Modern browsers (like the warez we're using in 2014/2015) want a certificate that chains back to a trust anchor, and they want DNS names to be presented in particular ways in the certificate. And browsers are actively moving against self-signed server certificates.
Some browsers don't exactly make it easy to import a self-signed server certificate. In fact, you can't with some browsers, like Android's browser. So the complete solution is to become your own authority.
In the absence of becoming your own authority, you have to get the DNS names right to give the certificate the greatest chance of success. But I would encourage you to become your own authority. It's easy to become your own authority, and it will sidestep all the trust issues (who better to trust than yourself?).
This is probably not the site you are looking for!
The site's security certificate is not trusted!
This is because browsers use a predefined list of trust anchors to validate server certificates. A self-signed certificate does not chain back to a trusted anchor.
The best way to avoid this is:
Create your own authority (i.e., become a CA)
Create a certificate signing request (CSR) for the server
Sign the server's CSR with your CA key
Install the server certificate on the server
Install the CA certificate on the client
Step 1 - Create your own authority just means to create a self-signed certificate with CA: true and proper key usage. That means the Subject and Issuer are the same entity, CA is set to true in Basic Constraints (it should also be marked as critical), key usage is keyCertSign and crlSign (if you are using CRLs), and the Subject Key Identifier (SKI) is the same as the Authority Key Identifier (AKI).
To become your own certificate authority, see *How do you sign a certificate signing request with your certification authority? on Stack Overflow. Then, import your CA into the Trust Store used by the browser.
Steps 2 - 4 are roughly what you do now for a public facing server when you enlist the services of a CA like Startcom or CAcert. Steps 1 and 5 allows you to avoid the third-party authority, and act as your own authority (who better to trust than yourself?).
The next best way to avoid the browser warning is to trust the server's certificate. But some browsers, like Android's default browser, do not let you do it. So it will never work on the platform.
The issue of browsers (and other similar user agents) not trusting self-signed certificates is going to be a big problem in the Internet of Things (IoT). For example, what is going to happen when you connect to your thermostat or refrigerator to program it? The answer is, nothing good as far as the user experience is concerned.
The W3C's WebAppSec Working Group is starting to look at the issue. See, for example, Proposal: Marking HTTP As Non-Secure.
How to create a self-signed certificate with OpenSSL
The commands below and the configuration file create a self-signed certificate (it also shows you how to create a signing request). They differ from other answers in one respect: the DNS names used for the self signed certificate are in the Subject Alternate Name (SAN), and not the Common Name (CN).
The DNS names are placed in the SAN through the configuration file with the line subjectAltName = #alternate_names (there's no way to do it through the command line). Then there's an alternate_names section in the configuration file (you should tune this to suit your taste):
[ alternate_names ]
DNS.1 = example.com
DNS.2 = www.example.com
DNS.3 = mail.example.com
DNS.4 = ftp.example.com
# Add these if you need them. But usually you don't want them or
# need them in production. You may need them for development.
# DNS.5 = localhost
# DNS.6 = localhost.localdomain
# IP.1 = 127.0.0.1
# IP.2 = ::1
It's important to put DNS name in the SAN and not the CN, because both the IETF and the CA/Browser Forums specify the practice. They also specify that DNS names in the CN are deprecated (but not prohibited). If you put a DNS name in the CN, then it must be included in the SAN under the CA/B policies. So you can't avoid using the Subject Alternate Name.
If you don't do put DNS names in the SAN, then the certificate will fail to validate under a browser and other user agents which follow the CA/Browser Forum guidelines.
Related: browsers follow the CA/Browser Forum policies; and not the IETF policies. That's one of the reasons a certificate created with OpenSSL (which generally follows the IETF) sometimes does not validate under a browser (browsers follow the CA/B). They are different standards, they have different issuing policies and different validation requirements.
Create a self signed certificate (notice the addition of -x509 option):
openssl req -config example-com.conf -new -x509 -sha256 -newkey rsa:2048 -nodes \
-keyout example-com.key.pem -days 365 -out example-com.cert.pem
Create a signing request (notice the lack of -x509 option):
openssl req -config example-com.conf -new -sha256 -newkey rsa:2048 -nodes \
-keyout example-com.key.pem -days 365 -out example-com.req.pem
Print a self-signed certificate:
openssl x509 -in example-com.cert.pem -text -noout
Print a signing request:
openssl req -in example-com.req.pem -text -noout
Configuration file (passed via -config option)
[ req ]
default_bits = 2048
default_keyfile = server-key.pem
distinguished_name = subject
req_extensions = req_ext
x509_extensions = x509_ext
string_mask = utf8only
# The Subject DN can be formed using X501 or RFC 4514 (see RFC 4519 for a description).
# Its sort of a mashup. For example, RFC 4514 does not provide emailAddress.
[ subject ]
countryName = Country Name (2 letter code)
countryName_default = US
stateOrProvinceName = State or Province Name (full name)
stateOrProvinceName_default = NY
localityName = Locality Name (eg, city)
localityName_default = New York
organizationName = Organization Name (eg, company)
organizationName_default = Example, LLC
# Use a friendly name here because it's presented to the user. The server's DNS
# names are placed in Subject Alternate Names. Plus, DNS names here is deprecated
# by both IETF and CA/Browser Forums. If you place a DNS name here, then you
# must include the DNS name in the SAN too (otherwise, Chrome and others that
# strictly follow the CA/Browser Baseline Requirements will fail).
commonName = Common Name (e.g. server FQDN or YOUR name)
commonName_default = Example Company
emailAddress = Email Address
emailAddress_default = test#example.com
# Section x509_ext is used when generating a self-signed certificate. I.e., openssl req -x509 ...
[ x509_ext ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
# You only need digitalSignature below. *If* you don't allow
# RSA Key transport (i.e., you use ephemeral cipher suites), then
# omit keyEncipherment because that's key transport.
basicConstraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment
subjectAltName = #alternate_names
nsComment = "OpenSSL Generated Certificate"
# RFC 5280, Section 4.2.1.12 makes EKU optional
# CA/Browser Baseline Requirements, Appendix (B)(3)(G) makes me confused
# In either case, you probably only need serverAuth.
# extendedKeyUsage = serverAuth, clientAuth
# Section req_ext is used when generating a certificate signing request. I.e., openssl req ...
[ req_ext ]
subjectKeyIdentifier = hash
basicConstraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment
subjectAltName = #alternate_names
nsComment = "OpenSSL Generated Certificate"
# RFC 5280, Section 4.2.1.12 makes EKU optional
# CA/Browser Baseline Requirements, Appendix (B)(3)(G) makes me confused
# In either case, you probably only need serverAuth.
# extendedKeyUsage = serverAuth, clientAuth
[ alternate_names ]
DNS.1 = example.com
DNS.2 = www.example.com
DNS.3 = mail.example.com
DNS.4 = ftp.example.com
# Add these if you need them. But usually you don't want them or
# need them in production. You may need them for development.
# DNS.5 = localhost
# DNS.6 = localhost.localdomain
# DNS.7 = 127.0.0.1
# IPv6 localhost
# DNS.8 = ::1
You may need to do the following for Chrome. Otherwise Chrome may complain a Common Name is invalid (ERR_CERT_COMMON_NAME_INVALID). I'm not sure what the relationship is between an IP address in the SAN and a CN in this instance.
# IPv4 localhost
# IP.1 = 127.0.0.1
# IPv6 localhost
# IP.2 = ::1
There are other rules concerning the handling of DNS names in X.509/PKIX certificates. Refer to these documents for the rules:
RFC 5280, Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
RFC 6125, Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)
RFC 6797, Appendix A, HTTP Strict Transport Security (HSTS)
RFC 7469, Public Key Pinning Extension for HTTP
CA/Browser Forum Baseline Requirements
CA/Browser Forum Extended Validation Guidelines
RFC 6797 and RFC 7469 are listed, because they are more restrictive than the other RFCs and CA/B documents. RFCs 6797 and 7469 do not allow an IP address, either.
Here are the options described in #diegows's answer, described in more detail, from the documentation:
openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days XXX
req
PKCS#10 certificate request and certificate generating utility.
-x509
this option outputs a self signed certificate instead of a certificate request.
This is typically used to generate a test certificate or a self signed root CA.
-newkey arg
this option creates a new certificate request and a new private key. The argument
takes one of several forms. rsa:nbits, where nbits is the number of bits,
generates an RSA key nbits in size.
-keyout filename
this gives the filename to write the newly created private key to.
-out filename
This specifies the output filename to write to or standard output by default.
-days n
when the -x509 option is being used this specifies the number of days to certify
the certificate for. The default is 30 days.
-nodes
if this option is specified then if a private key is created it will not be encrypted.
The documentation is actually more detailed than the above; I just summarized it here.
I can't comment, so I will put this as a separate answer. I found a few issues with the accepted one-liner answer:
The one-liner includes a passphrase in the key.
The one-liner uses SHA-1 which in many browsers throws warnings in console.
Here is a simplified version that removes the passphrase, ups the security to suppress warnings and includes a suggestion in comments to pass in -subj to remove the full question list:
openssl genrsa -out server.key 2048
openssl rsa -in server.key -out server.key
openssl req -sha256 -new -key server.key -out server.csr -subj '/CN=localhost'
openssl x509 -req -sha256 -days 365 -in server.csr -signkey server.key -out server.crt
Replace 'localhost' with whatever domain you require. You will need to run the first two commands one by one as OpenSSL will prompt for a passphrase.
To combine the two into a .pem file:
cat server.crt server.key > cert.pem
Modern browsers now throw a security error for otherwise well-formed self-signed certificates if they are missing a SAN (Subject Alternate Name). OpenSSL does not provide a command-line way to specify this, so many developers' tutorials and bookmarks are suddenly outdated.
The quickest way to get running again is a short, stand-alone conf file:
Create an OpenSSL config file (example: req.cnf)
[req]
distinguished_name = req_distinguished_name
x509_extensions = v3_req
prompt = no
[req_distinguished_name]
C = US
ST = VA
L = SomeCity
O = MyCompany
OU = MyDivision
CN = www.company.com
[v3_req]
keyUsage = critical, digitalSignature, keyAgreement
extendedKeyUsage = serverAuth
subjectAltName = #alt_names
[alt_names]
DNS.1 = www.company.com
DNS.2 = company.com
DNS.3 = company.net
Create the certificate referencing this config file
openssl req -x509 -nodes -days 730 -newkey rsa:2048 \
-keyout cert.key -out cert.pem -config req.cnf -sha256
Example config from https://support.citrix.com/article/CTX135602
I would recommend to add the -sha256 parameter, to use the SHA-2 hash algorithm, because major browsers are considering to show "SHA-1 certificates" as not secure.
The same command line from the accepted answer - #diegows with added -sha256
openssl req -x509 -sha256 -newkey rsa:2048 -keyout key.pem -out cert.pem -days XXX
More information in Google Security blog.
Update May 2018. As many noted in the comments that using SHA-2 does not add any security to a self-signed certificate. But I still recommend using it as a good habit of not using outdated / insecure cryptographic hash functions. Full explanation is available in Why is it fine for certificates above the end-entity certificate to be SHA-1 based?.
I can`t comment so I add a separate answer.
I tried to create a self-signed certificate for NGINX and it was easy, but when I wanted to add it to Chrome white list I had a problem. And my solution was to create a Root certificate and signed a child certificate by it.
So step by step.
Create file config_ssl_ca.cnf
Notice, config file has an option basicConstraints=CA:true which means that this certificate is supposed to be root.
This is a good practice, because you create it once and can reuse.
[ req ]
default_bits = 2048
prompt = no
distinguished_name=req_distinguished_name
req_extensions = v3_req
[ req_distinguished_name ]
countryName=UA
stateOrProvinceName=root region
localityName=root city
organizationName=Market(localhost)
organizationalUnitName=roote department
commonName=market.localhost
emailAddress=root_email#root.localhost
[ alternate_names ]
DNS.1 = market.localhost
DNS.2 = www.market.localhost
DNS.3 = mail.market.localhost
DNS.4 = ftp.market.localhost
DNS.5 = *.market.localhost
[ v3_req ]
keyUsage=digitalSignature
basicConstraints=CA:true
subjectKeyIdentifier = hash
subjectAltName = #alternate_names
Next config file for your child certificate will be call config_ssl.cnf.
[ req ]
default_bits = 2048
prompt = no
distinguished_name=req_distinguished_name
req_extensions = v3_req
[ req_distinguished_name ]
countryName=UA
stateOrProvinceName=Kyiv region
localityName=Kyiv
organizationName=market place
organizationalUnitName=market place department
commonName=market.localhost
emailAddress=email#market.localhost
[ alternate_names ]
DNS.1 = market.localhost
DNS.2 = www.market.localhost
DNS.3 = mail.market.localhost
DNS.4 = ftp.market.localhost
DNS.5 = *.market.localhost
[ v3_req ]
keyUsage=digitalSignature
basicConstraints=CA:false
subjectAltName = #alternate_names
subjectKeyIdentifier = hash
The first step - create Root key and certificate
openssl genrsa -out ca.key 2048
openssl req -new -x509 -key ca.key -out ca.crt -days 365 -config config_ssl_ca.cnf
The second step creates child key and file CSR - Certificate Signing Request. Because the idea is to sign the child certificate by root and get a correct certificate
openssl genrsa -out market.key 2048
openssl req -new -sha256 -key market.key -config config_ssl.cnf -out market.csr
Open Linux terminal and do this command
echo 00 > ca.srl
touch index.txt
The ca.srl text file containing the next serial number to use in hex.
Mandatory. This file must be present and contain a valid serial number.
Last Step, create one more config file and call it config_ca.cnf
# we use 'ca' as the default section because we're usign the ca command
[ ca ]
default_ca = my_ca
[ my_ca ]
# a text file containing the next serial number to use in hex. Mandatory.
# This file must be present and contain a valid serial number.
serial = ./ca.srl
# the text database file to use. Mandatory. This file must be present though
# initially it will be empty.
database = ./index.txt
# specifies the directory where new certificates will be placed. Mandatory.
new_certs_dir = ./
# the file containing the CA certificate. Mandatory
certificate = ./ca.crt
# the file contaning the CA private key. Mandatory
private_key = ./ca.key
# the message digest algorithm. Remember to not use MD5
default_md = sha256
# for how many days will the signed certificate be valid
default_days = 365
# a section with a set of variables corresponding to DN fields
policy = my_policy
# MOST IMPORTANT PART OF THIS CONFIG
copy_extensions = copy
[ my_policy ]
# if the value is "match" then the field value must match the same field in the
# CA certificate. If the value is "supplied" then it must be present.
# Optional means it may be present. Any fields not mentioned are silently
# deleted.
countryName = match
stateOrProvinceName = supplied
organizationName = supplied
commonName = market.localhost
organizationalUnitName = optional
commonName = supplied
You may ask, why so difficult, why we must create one more config to sign child certificate by root. The answer is simple because child certificate must have a SAN block - Subject Alternative Names.
If we sign the child certificate by "openssl x509" utils, the Root certificate will delete the SAN field in child certificate.
So we use "openssl ca" instead of "openssl x509" to avoid the deleting of the SAN field. We create a new config file and tell it to copy all extended fields copy_extensions = copy.
openssl ca -config config_ca.cnf -out market.crt -in market.csr
The program asks you 2 questions:
Sign the certificate? Say "Y"
1 out of 1 certificate requests certified, commit? Say "Y"
In terminal you can see a sentence with the word "Database", it means file index.txt which you create by the command "touch". It will contain all information by all certificates you create by "openssl ca" util.
To check the certificate valid use:
openssl rsa -in market.key -check
If you want to see what inside in CRT:
openssl x509 -in market.crt -text -noout
If you want to see what inside in CSR:
openssl req -in market.csr -noout -text
This is the script I use on local boxes to set the SAN (subjectAltName) in self-signed certificates.
This script takes the domain name (example.com) and generates the SAN for *.example.com and example.com in the same certificate. The sections below are commented. Name the script (e.g. generate-ssl.sh) and give it executable permissions. The files will be written to the same directory as the script.
Chrome 58 an onward requires SAN to be set in self-signed certificates.
#!/usr/bin/env bash
# Set the TLD domain we want to use
BASE_DOMAIN="example.com"
# Days for the cert to live
DAYS=1095
# A blank passphrase
PASSPHRASE=""
# Generated configuration file
CONFIG_FILE="config.txt"
cat > $CONFIG_FILE <<-EOF
[req]
default_bits = 2048
prompt = no
default_md = sha256
x509_extensions = v3_req
distinguished_name = dn
[dn]
C = CA
ST = BC
L = Vancouver
O = Example Corp
OU = Testing Domain
emailAddress = webmaster#$BASE_DOMAIN
CN = $BASE_DOMAIN
[v3_req]
subjectAltName = #alt_names
[alt_names]
DNS.1 = *.$BASE_DOMAIN
DNS.2 = $BASE_DOMAIN
EOF
# The file name can be anything
FILE_NAME="$BASE_DOMAIN"
# Remove previous keys
echo "Removing existing certs like $FILE_NAME.*"
chmod 770 $FILE_NAME.*
rm $FILE_NAME.*
echo "Generating certs for $BASE_DOMAIN"
# Generate our Private Key, CSR and Certificate
# Use SHA-2 as SHA-1 is unsupported from Jan 1, 2017
openssl req -new -x509 -newkey rsa:2048 -sha256 -nodes -keyout "$FILE_NAME.key" -days $DAYS -out "$FILE_NAME.crt" -passin pass:$PASSPHRASE -config "$CONFIG_FILE"
# OPTIONAL - write an info to see the details of the generated crt
openssl x509 -noout -fingerprint -text < "$FILE_NAME.crt" > "$FILE_NAME.info"
# Protect the key
chmod 400 "$FILE_NAME.key"
This script also writes an information file, so you can inspect the new certificate and verify the SAN is set properly.
...
28:dd:b8:1e:34:b5:b1:44:1a:60:6d:e3:3c:5a:c4:
da:3d
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Alternative Name:
DNS:*.example.com, DNS:example.com
Signature Algorithm: sha256WithRSAEncryption
3b:35:5a:d6:9e:92:4f:fc:f4:f4:87:78:cd:c7:8d:cd:8c:cc:
...
If you are using Apache, then you can reference the above certificate in your configuration file like so:
<VirtualHost _default_:443>
ServerName example.com
ServerAlias www.example.com
DocumentRoot /var/www/htdocs
SSLEngine on
SSLCertificateFile path/to/your/example.com.crt
SSLCertificateKeyFile path/to/your/example.com.key
</VirtualHost>
Remember to restart your Apache (or Nginx, or IIS) server for the new certificate to take effect.
2017 one-liner:
openssl req \
-newkey rsa:2048 \
-x509 \
-nodes \
-keyout server.pem \
-new \
-out server.pem \
-subj /CN=localhost \
-reqexts SAN \
-extensions SAN \
-config <(cat /System/Library/OpenSSL/openssl.cnf \
<(printf '[SAN]\nsubjectAltName=DNS:localhost')) \
-sha256 \
-days 3650
This also works in Chrome 57, as it provides the SAN, without having another configuration file.
It was taken from an answer here.
This creates a single .pem file that contains both the private key and cert. You can move them to separate .pem files if needed.
Generate a key without password and certificate for 10 years, the short way:
openssl req -x509 -nodes -new -keyout server.key -out server.crt -days 3650 -subj "/C=/ST=/L=/O=/OU=web/CN=www.server.com"
for the flag -subj | -subject empty values are permitted -subj "/C=/ST=/L=/O=/OU=web/CN=www.server.com", but you can sets more details as you like:
C - Country Name (2 letter code)
ST - State
L - Locality Name (eg, city)
O - Organization Name
OU - Organizational Unit Name
CN - Common Name - required!
One-liner version 2017:
CentOS:
openssl req -x509 -nodes -sha256 -newkey rsa:2048 \
-keyout localhost.key -out localhost.crt \
-days 3650 \
-subj "CN=localhost" \
-reqexts SAN -extensions SAN \
-config <(cat /etc/pki/tls/openssl.cnf <(printf "\n[SAN]\nsubjectAltName=IP:127.0.0.1,DNS:localhost"))
Ubuntu:
openssl req -x509 -nodes -sha256 -newkey rsa:2048 \
-keyout localhost.key -out localhost.crt \
-days 3650 \
-subj "/CN=localhost" \
-reqexts SAN -extensions SAN \
-config <(cat /etc/ssl/openssl.cnf <(printf "\n[SAN]\nsubjectAltName=IP:127.0.0.1,DNS:localhost"))
Edit: added prepending Slash to 'subj' option for Ubuntu.
openssl allows to generate self-signed certificate by a single command (-newkey
instructs to generate a private key and -x509 instructs to issue a self-signed
certificate instead of a signing request)::
openssl req -x509 -newkey rsa:4096 \
-keyout my.key -passout pass:123456 -out my.crt \
-days 365 \
-subj /CN=localhost/O=home/C=US/emailAddress=me#mail.internal \
-addext "subjectAltName = DNS:localhost,DNS:web.internal,email:me#mail.internal" \
-addext keyUsage=digitalSignature -addext extendedKeyUsage=serverAuth
You can generate a private key and construct a self-signing certificate in separate steps::
openssl genrsa -out my.key -passout pass:123456 2048
openssl req -x509 \
-key my.key -passin pass:123456 -out my.csr \
-days 3650 \
-subj /CN=localhost/O=home/C=US/emailAddress=me#mail.internal \
-addext "subjectAltName = DNS:localhost,DNS:web.internal,email:me#mail.internal" \
-addext keyUsage=digitalSignature -addext extendedKeyUsage=serverAuth
Review the resulting certificate::
openssl x509 -text -noout -in my.crt
Java keytool creates PKCS#12 store::
keytool -genkeypair -keystore my.p12 -alias master \
-storetype pkcs12 -keyalg RSA -keysize 2048 -validity 3650 \
-storepass 123456 \
-dname "CN=localhost,O=home,C=US" \
-ext 'san=dns:localhost,dns:web.internal,email:me#mail.internal'
To export the self-signed certificate::
keytool -exportcert -keystore my.p12 -file my.crt \
-alias master -rfc -storepass 123456
Review the resulting certificate::
keytool -printcert -file my.crt
certtool from GnuTLS doesn't allow passing different attributes from CLI. I don't like to mess with config files ((
Generate keys
I am using /etc/mysql for cert storage because /etc/apparmor.d/usr.sbin.mysqld contains /etc/mysql/*.pem r.
sudo su -
cd /etc/mysql
openssl genrsa -out ca-key.pem 2048;
openssl req -new -x509 -nodes -days 1000 -key ca-key.pem -out ca-cert.pem;
openssl req -newkey rsa:2048 -days 1000 -nodes -keyout server-key.pem -out server-req.pem;
openssl x509 -req -in server-req.pem -days 1000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 -out server-cert.pem;
openssl req -newkey rsa:2048 -days 1000 -nodes -keyout client-key.pem -out client-req.pem;
openssl x509 -req -in client-req.pem -days 1000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 -out client-cert.pem;
Add configuration
/etc/mysql/my.cnf
[client]
ssl-ca=/etc/mysql/ca-cert.pem
ssl-cert=/etc/mysql/client-cert.pem
ssl-key=/etc/mysql/client-key.pem
[mysqld]
ssl-ca=/etc/mysql/ca-cert.pem
ssl-cert=/etc/mysql/server-cert.pem
ssl-key=/etc/mysql/server-key.pem
On my setup, Ubuntu server logged to: /var/log/mysql/error.log
Follow up notes:
SSL error: Unable to get certificate from '...'
MySQL might be denied read access to your certificate file if it is not in apparmors configuration. As mentioned in the previous steps^, save all our certificates as .pem files in the /etc/mysql/ directory which is approved by default by apparmor (or modify your apparmor/SELinux to allow access to wherever you stored them.)
SSL error: Unable to get private key
Your MySQL server version may not support the default rsa:2048 format
Convert generated rsa:2048 to plain rsa with:
openssl rsa -in server-key.pem -out server-key.pem
openssl rsa -in client-key.pem -out client-key.pem
Check if local server supports SSL:
mysql -u root -p
mysql> show variables like "%ssl%";
+---------------+----------------------------+
| Variable_name | Value |
+---------------+----------------------------+
| have_openssl | YES |
| have_ssl | YES |
| ssl_ca | /etc/mysql/ca-cert.pem |
| ssl_capath | |
| ssl_cert | /etc/mysql/server-cert.pem |
| ssl_cipher | |
| ssl_key | /etc/mysql/server-key.pem |
+---------------+----------------------------+
Verifying a connection to the database is SSL encrypted:
Verifying connection
When logged in to the MySQL instance, you can issue the query:
show status like 'Ssl_cipher';
If your connection is not encrypted, the result will be blank:
mysql> show status like 'Ssl_cipher';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Ssl_cipher | |
+---------------+-------+
1 row in set (0.00 sec)
Otherwise, it would show a non-zero length string for the cypher in use:
mysql> show status like 'Ssl_cipher';
+---------------+--------------------+
| Variable_name | Value |
+---------------+--------------------+
| Ssl_cipher | DHE-RSA-AES256-SHA |
+---------------+--------------------+
1 row in set (0.00 sec)
Require ssl for specific user's connection ('require ssl'):
SSL
Tells the server to permit only SSL-encrypted connections for the account.
GRANT ALL PRIVILEGES ON test.* TO 'root'#'localhost'
REQUIRE SSL;
To connect, the client must specify the --ssl-ca option to authenticate the server certificate, and may additionally specify the --ssl-key and --ssl-cert options. If neither --ssl-ca option nor --ssl-capath option is specified, the client does not authenticate the server certificate.
Alternate link: Lengthy tutorial in Secure PHP Connections to MySQL with SSL.
One liner FTW. I like to keep it simple. Why not use one command that contains ALL the arguments needed? This is how I like it - this creates an x509 certificate and its PEM key:
openssl req -x509 \
-nodes -days 365 -newkey rsa:4096 \
-keyout self.key.pem \
-out self-x509.crt \
-subj "/C=US/ST=WA/L=Seattle/CN=example.com/emailAddress=someEmail#gmail.com"
That single command contains all the answers you would normally provide for the certificate details. This way you can set the parameters and run the command, get your output - then go for coffee.
>> More here <<
You have the general procedure correct. The syntax for the command is below.
openssl req -new -key {private key file} -out {output file}
However, the warnings are displayed, because the browser was not able to verify the identify by validating the certificate with a known Certificate Authority (CA).
As this is a self-signed certificate there is no CA and you can safely ignore the warning and proceed. Should you want to get a real certificate that will be recognizable by anyone on the public Internet then the procedure is below.
Generate a private key
Use that private key to create a CSR file
Submit CSR to CA (Verisign or others, etc.)
Install received cert from CA on web server
Add other certs to authentication chain depending on the type cert
I have more details about this in a post at Securing the Connection: Creating a Security Certificate with OpenSSL
As has been discussed in detail, self-signed certificates are not trusted for the Internet. You can add your self-signed certificate to many but not all browsers. Alternatively you can become your own certificate authority.
The primary reason one does not want to get a signed certificate from a certificate authority is cost -- Symantec charges between $995 - $1,999 per year for certificates -- just for a certificate intended for internal network, Symantec charges $399 per year. That cost is easy to justify if you are processing credit card payments or work for the profit center of a highly profitable company. It is more than many can afford for a personal project one is creating on the internet, or for a non-profit running on a minimal budget, or if one works in a cost center of an organization -- cost centers always try to do more with less.
An alternative is to use certbot (see about certbot). Certbot is an easy-to-use automatic client that fetches and deploys SSL/TLS certificates for your web server.
If you setup certbot, you can enable it to create and maintain a certificate for you issued by the Let’s Encrypt certificate authority.
I did this over the weekend for my organization. I installed the required packages for certbot on my server (Ubuntu 16.04) and then ran the command necessary to setup and enable certbot. One likely needs a DNS plugin for certbot - we are presently using DigitalOcean though may be migrating to another service soon.
Note that some of the instructions were not quite right and took a little poking and time with Google to figure out. This took a fair amount of my time the first time but now I think I could do it in minutes.
For DigitalOcean, one area I struggled was when I was prompted to input the path to your DigitalOcean credentials INI file. What the script is referring to is the Applications & API page and the Tokens/Key tab on that page. You need to have or generate a personal access token (read and write) for DigitalOcean's API -- this is a 65 character hexadecimal string. This string then needs to be put into a file on the webserver from which you are running certbot. That file can have a comment as its first line (comments start with #). The seccond line is:
dns_digitalocean_token = 0000111122223333444455556666777788889999aaaabbbbccccddddeeeeffff
Once I figured out how to set up a read+write token for DigitalOcean's API, it was pretty easy to use certbot to setup a wildcard certificate. Note that one does not have to setup a wildcard certificate, one may instead specify each domain and sub-domain that one wants the certificate to appply to. It was the wildcard certificate that required the credentials INI file that contained the personal access token from DigitalOcean.
Note that public key certificates (also known as identity certificates or SSL certificates) expire and require renewal. Thus you will need to renew your certificate on a periodic (reoccurring) basis. The certbot documentation covers renewing certificates.
My plan is to write a script to use the openssl command to get my certificate's expiration date and to trigger renewal when it is 30 days or less until it expires. I will then add this script to cron and run it once per day.
Here is the command to read your certificate's expiration date:
root#prod-host:~# /usr/bin/openssl x509 -enddate -noout -in path-to-certificate-pem-file
notAfter=May 25 19:24:12 2019 GMT
After much of going around, playing with various solutions, still I faced the problem that issuing a self-signed certificate for localhost, gave me error
ERR_CERT_INVALID
When expanding the details, chrome said:
You cannot visit localhost right now because the website sent
scrambled credentials...
And the only ugly way to get through is to type (directly in this screen, without seeing any cursor for the text) :
(type in the keyboard) thisisunsafe
Which let me proceed.
Until I found extendedKeyUsage = serverAuth, clientAuth
TL;DR
openssl genrsa -out localhost.key 2048
openssl req -key localhost.key -new -out localhost.csr
(click enter on everything and just fill in the common name (CN) with localhost or your other FQDN.
put the following in a file named v3.ext (edit whatever you need):
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer:always
basicConstraints = CA:TRUE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment, keyAgreement, keyCertSign
extendedKeyUsage = serverAuth, clientAuth
subjectAltName = DNS:localhost, DNS:localhost.localdomain
issuerAltName = issuer:copy
openssl x509 -req -in localhost.csr -signkey localhost.key -out localhost.pem -days 3650 -sha256 -extfile v3.ext
And voilà!
You can visit the website, expand "Advanced" and click "Proceed to localhost (unsafe)".
this worked for me
openssl req -x509 -nodes -subj '/CN=localhost' -newkey rsa:4096 -keyout ./sslcert/key.pem -out ./sslcert/cert.pem -days 365
server.js
var fs = require('fs');
var path = require('path');
var http = require('http');
var https = require('https');
var compression = require('compression');
var express = require('express');
var app = express();
app.use(compression());
app.use(express.static(__dirname + '/www'));
app.get('/*', function(req,res) {
res.sendFile(path.join(__dirname+'/www/index.html'));
});
// your express configuration here
var httpServer = http.createServer(app);
var credentials = {
key: fs.readFileSync('./sslcert/key.pem', 'utf8'),
cert: fs.readFileSync('./sslcert/cert.pem', 'utf8')
};
var httpsServer = https.createServer(credentials, app);
httpServer.listen(8080);
httpsServer.listen(8443);
console.log(`RUNNING ON http://127.0.0.1:8080`);
console.log(`RUNNING ON http://127.0.0.1:8443`);
Quick command line: Minimal Version
"I want a self signed certificate, in pfx form, for www.example.com with minimal fuss":
openssl req -x509 -sha256 -days 365 -nodes -out cert.crt -keyout cert.key -subj "/CN=www.example.com"
openssl pkcs12 -export -out cert.pfx -inkey cert.key -in cert.crt
This very simple Python app that creates a self-signed certificate.
Code:
from OpenSSL import crypto, SSL
from secrets import randbelow
print("Please know, if you make a mistake, you must restart the program.")
def cert_gen(
emailAddress=input("Enter Email Address: "),
commonName=input("Enter Common Name: "),
countryName=input("Enter Country Name (2 characters): "),
localityName=input("Enter Locality Name: "),
stateOrProvinceName=input("Enter State of Province Name: "),
organizationName=input("Enter Organization Name: "),
organizationUnitName=input("Enter Organization Unit Name: "),
serialNumber=randbelow(1000000),
validityStartInSeconds=0,
validityEndInSeconds=10*365*24*60*60,
KEY_FILE = "private.key",
CERT_FILE="selfsigned.crt"):
#can look at generated file using openssl:
#openssl x509 -inform pem -in selfsigned.crt -noout -text
# create a key pair
k = crypto.PKey()
k.generate_key(crypto.TYPE_RSA, 4096)
# create a self-signed cert
cert = crypto.X509()
cert.get_subject().C = countryName
cert.get_subject().ST = stateOrProvinceName
cert.get_subject().L = localityName
cert.get_subject().O = organizationName
cert.get_subject().OU = organizationUnitName
cert.get_subject().CN = commonName
cert.get_subject().emailAddress = emailAddress
cert.set_serial_number(serialNumber)
cert.gmtime_adj_notBefore(0)
cert.gmtime_adj_notAfter(validityEndInSeconds)
cert.set_issuer(cert.get_subject())
cert.set_pubkey(k)
cert.sign(k, 'sha512')
with open(CERT_FILE, "wt") as f:
f.write(crypto.dump_certificate(crypto.FILETYPE_PEM, cert).decode("utf-8"))
with open(KEY_FILE, "wt") as f:
f.write(crypto.dump_privatekey(crypto.FILETYPE_PEM, k).decode("utf-8"))
print("GENERATED")
input("Press enter to close program.")
cert_gen()
However, you still get the "certificate is not trusted" error. This is because of a few reasons:
It is self-signed/not verified (a verified certificate would need a CA (Certificate Authority), like Let's Encrypt to be trusted on all devices).
It is not trusted on your machine. (this answer shows how you can make Windows trust your certificate).
If you want to generate self signed certificates using open ssl - here is a script we have generated which can be used as is.
#!/bin/bash
subj='//SKIP=skip/C=IN/ST=Country/L=City/O=MyCompany/OU=Technology'
red='\033[31m' # red
yellow='\033[33m' # yellow
green='\033[32m' # green
blue='\033[34m' # Blue
purple='\033[35m' # Purple
cyan='\033[36m' # Cyan
white='\033[37m' # White
gencerts(){
certname=$1
pkname=$2
alias=$3
$(openssl genrsa -out $pkname'pem.pem' 4096)
$(openssl req -new -sha256 -key $pkname'pem.pem' -out $certname'csr.csr' -subj $subj)
$(openssl x509 -req -sha256 -days 3650 -in $certname'csr.csr' -signkey $pkname'pem.pem' -out $certname'.crt')
$(openssl pkcs12 -export -out $pkname'.p12' -name $alias -inkey $pkname'pem.pem' -in $certname'.crt')
}
verify(){
pkname=$1
keytool -v -list -storetype pkcs12 -keystore $pkname'.p12'
}
echo -e "${purple}WELCOME TO KEY PAIR GENERATOR"
echo -e "${yellow} Please enter the name of the certificate required: "
read certname
echo -e "${green}Please enter the name of the Private Key p12 file required: "
read pkname
echo -e "${cyan}Please enter the ALIAS of the Private Key p12 file : "
read pkalias
echo -e "${white}Please wait while we generate your Key Pair"
gencerts $certname $pkname $pkalias
echo -e "${white}Now lets verify the private key :)"
tput bel # Play a bell
verify $pkname
Do let me know if any improvements can be made to the script.
You don't need to use openssl's bad user interface at all! Try mkcert.
$ brew install mkcert nss
[...]
$ mkcert -install
Created a new local CA 💥
The local CA is now installed in the system trust store! ⚡️
The local CA is now installed in the Firefox trust store (requires browser restart)! 🦊
$ mkcert example.com "*.example.com" example.test localhost 127.0.0.1 ::1
Created a new certificate valid for the following names 📜
- "example.com"
- "*.example.com"
- "example.test"
- "localhost"
- "127.0.0.1"
- "::1"
The certificate is at "./example.com+5.pem" and the key at "./example.com+5-key.pem" ✅