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
Related
I have a basic nginx home server setup which i use Client certificates to allow outside access. I have followed this guide to get everything setup which works as expected:
https://gist.github.com/rkaramandi/20a04a41536f3d7e6d2f26b0b9605ab6
in summary:
openssl genrsa -aes256 -out ca.privkey 4096
openssl req -new -x509 -days 365 -key ca.privkey -out ca.crt
openssl genrsa -aes256 -out bobs-ipad.privkey 4096
openssl req -new -out bobs-ipad.csr -key bobs-ipad.privkey
openssl x509 -req -days 365 -in bobs-ipad.csr -CA ca.crt -CAkey ca.privkey -set_serial 100 -out bobs-ipad.crt
openssl pkcs12 -export -clcerts -in bobs-ipad.crt -inkey bobs-ipad.privkey -out bobs-ipad.p12
Also openssl pkcs12 -in bobs-ipad.p12 -out bobs-ipad.pem -nodes to generate a pem file as well.
And in nginx config:
ssl_client_certificate <path>/ca.crt;
# ssl_crl <path>/ca.crl;
ssl_verify_client optional;
...
location / {
if ($ssl_client_verify != SUCCESS) {
return 403;
}
I am able to access the server from outside and only signed certificates on the client machine allow access.
However if one of the signed certificates were to be compromised i'd have to re-generate the CA and re-distribute the new signed client certificates. I understand that a CRL file can be used to revoke certificates using ssl_crl <path to crl>; in the nginx config but i am not sure to generate this using the guide i followed.
A command like this can be used openssl ca -gencrl -keyfile ca.privkey -cert ca.crt -out ca.crl
But this relies on a configuration file with an index of the certificates i believe?
Is there anyway of using a command like the above to input a (or list of) pem or p12 client certificate(s) -in bobs-ipad.pem that i want to revoke?
If not perhaps i need to start again and have a config with index file to then -revoke the certificates and re-generate the crl file.
Thanks in advance,
Richard
It doesn't seem like this is possible. I have found some other guides to get this working with a configuration file (and generating a new CA): https://arcweb.co/securing-websites-nginx-and-client-side-certificate-authentication-linux/
https://www.djouxtech.net/posts/nginx-client-certificate-authentication/
How can disable the hostnameverfifier in gRPC to avoid exception below?
java.security.cert.CertificateException: No subject alternative names present
The recommended way to use test certificates where the hostname doesn't match is to call ManagedChannelBuilder.overrideAuthority("test-hostname"). This is functionally similar to adding test-hostname to /etc/hosts. This allows you to choose different IPs/DNS names with forAddress()/forTarget() without disabling security.
But it still seems like your certificate is a bit broken. Subject Alternative Name is required; using the certificate's Subject had been deprecated for a decades.
You may also be interested in using gRPC's test certificates. We provide TlsTesting to load them.
server = ServerBuilder.forPort(0)
// Use test cert on server-side
.useTransportSecurity(
TlsTesting.loadCert("server1.pem"),
TlsTesting.loadCert("server1.key"))
// ...
.build().start();
channel = NettyChannelBuilder
.forAddress("localhost", server.getPort())
// Trust test CA on client-side
.sslContext(
GrpcSslContexts.forClient()
.trustManager(TlsTesting.loadCert("ca.pem"))
.build())
// Change hostname to match certificate
.overrideAuthority("foo.test.google.fr")
.build();
Just to elaborate on #Eric Anderson answer. In the gRPC's test certificates he points to there are 2 types *.cnf files used to generate the client and server certs
1.Generate client cert: openssl.cnf
2.Generate server cert: server1-openssl.cnf
at the very bottom of both files you will find the hostnames where you need to add the matching entries for the client and server
for example if you are local testing for client and server resolving on "localhost" then you would need for both openssl.cnf and server1-openssl.cnf to have
[alt_names]
DNS.1 = localhost
after this you would need to regenerate the certificates
here is a simple script based on the grpc-java info here
#!/bin/bash
SERVER_CN=localhost
CLIENT_CN=localhost # Used when doing mutual TLS
TLS_KEY_PSSWD=somepsswd
echo "When prompted for cert information, everything is default except the common name which is set to localhost"
echo Generate CA key:
openssl genrsa -passout pass:TLS_KEY_PSSWD -des3 -out ca.key 4096
echo Generate CA:
openssl req -passin pass:TLS_KEY_PSSWD -x509 -new -nodes -key ca.key -out ca.pem -config conf/ca-openssl.cnf -days 3650 -extensions v3_req -subj "/CN=${SERVER_CN}"
echo "Now that we’re a CA on all our devices, we can sign certificates for any new dev sites that need HTTPS"
echo Generate client key:
openssl genrsa -out client.key.rsa 1024
openssl pkcs8 -topk8 -in client.key.rsa -out client.key -nocrypt
rm client.key.rsa
echo Generate client signing request:
openssl req -passin pass:TLS_KEY_PSSWD -new -key client.key -out client.csr -subj "/CN=${CLIENT_CN}"
echo Generate client cert:
openssl ca -passin pass:TLS_KEY_PSSWD -in client.csr -out client.pem -keyfile ca.key -cert ca.pem -verbose -config conf/openssl.cnf -days 3650 -updatedb
openssl x509 -in client.pem -out client.pem -outform PEM
echo Generate server key:
openssl genrsa -passout pass:TLS_KEY_PSSWD -out server1.key.rsa 1024
openssl pkcs8 -topk8 -in server1.key.rsa -out server1.key -nocrypt
rm server1.key.rsa
echo Generate server signing request:
openssl req -passin pass:TLS_KEY_PSSWD -new -key server1.key -out server1.csr -config conf/server1-openssl.cnf -subj "/CN=${CLIENT_CN}"
echo Generate server cert:
openssl ca -passin pass:TLS_KEY_PSSWD -in server1.csr -out server1.pem -keyfile ca.key -cert ca.pem -verbose -config conf/server1-openssl.cnf -days 3650 -extensions v3_req -updatedb
openssl x509 -in server1.pem -out server1.pem -outform PEM
I'm using Mosquitto version 1.4.8 on my test PC and the server. The server is accessible via ha.euroicc.com.
I've generated certificates and keys using the following script:
#! /usr/bin/env bash
# Create the CA Key and Certificate for signing Client Certs
openssl genrsa -out ca.key 4096
openssl req -new -x509 -days 365 -key ca.key -out ca.crt
# Create the Server Key, CSR, and Certificate
openssl genrsa -out server.key 1024
openssl req -new -key server.key -out server.csr
# We're self signing our own server cert here. This is a no-no in production.
openssl x509 -req -days 365 -in server.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out server.crt
# Create the Client Key and CSR
openssl genrsa -out client.key 1024
openssl req -new -key client.key -out client.csr
# Sign the client certificate with our CA cert. Unlike signing our own server cert, this is what we want to do.
# Serial should be different from the server one, otherwise curl will return NSS error -8054
openssl x509 -req -days 365 -in client.csr -CA ca.crt -CAkey ca.key -set_serial 02 -out client.crt
# Verify Server Certificate
openssl verify -purpose sslserver -CAfile ca.crt server.crt
# Verify Client Certificate
openssl verify -purpose sslclient -CAfile ca.crt client.crt
I've put 'd', 'dd' and 'dddd' everywhere except for common name.
The common name for ca is 'd' and for server/client is 'ha.euroicc.com'.
CN for server/client needs to be this value, or it doesn't work at all!
My current mosquitto config file:
pid_file /var/run/mosquitto.pid
persistence true
persistence_location /var/lib/mosquitto/
persistence_file mosquitto.db
log_dest syslog
log_dest stdout
log_dest topic
log_type error
log_type warning
log_type notice
log_type information
connection_messages true
log_timestamp true
password_file /etc/mosquitto/passwd
log_dest file /var/log/mosquitto/mosquitto.log
include_dir /etc/mosquitto/conf.d
allow_anonymous false
port 8883
cafile /etc/mosquitto/certs/ca.crt
keyfile /etc/mosquitto/certs/server.key
certfile /etc/mosquitto/certs/server.crt
require_certificate true
I use this command to subscribe from test PC:
mosquitto_sub -h ha.euroicc.com -t "topic/test" -u "damjan" -P "damjan" -p 8883 --cafile ca.crt --key client.key --cert client.crt
And get these errors:
On test PC:
Error: A TLS error occurred.
On server:
1532564086: OpenSSL Error: error:14089086:SSL
routines:ssl3_get_client_certificate:certificate verify failed
1532564086: Socket error on client <unknown>, disconnecting.
I've tried without require_certificate set on the server side, and not using client key/cert on the client side and subscription works in this case. This means that username/password parameters are fine.
That means that I either generated certificates and keys with a problem, my mosquitto.conf is bad or I'm using mosquitto_sub with a problem. Maybe something else?
I'm really at loss here and can't figure out what to try next...
Every bit of information helps.
Had a similar issue while upgrading to 2.0 because of the updated TLS/SSL bindings several know weak algorithms are not supported anymore.
In my case the signature of the certificate was sha1WithRSAEncryption where sha1 is the weak part. The same would be for e.g. MD5.
Check your certificate with openssl x509 -text -noout -in your.crt
Resigning the certificate with sha256WithRSAEncryption fixed it for me.
There is no need to create a new key.
You can either create a new CSR from your existing key and information from your certificate:
openssl x509 -x509toreq -in sha1.crt -signkey sha1.key -out sha256-new.csr -sha256
or overwrite the algorithm while signing the existing CSR again:
openssl x509 -req -days 360 -in sha1.csr -CA DummyCA-DonotTrust.pem -CAkey DummyCA-DonotTrust.pem -CAcreateserial -out sha256.crt -sha256
Recent openssl version should use sha256 as default.
Debian has changed the default setting with openssl-1.1.1 see https://wiki.debian.org/ContinuousIntegration/TriagingTips/openssl-1.1.1 and set CipherString = DEFAULT#SECLEVEL=2.
To get a list of supported algorithms run: openssl ciphers -s -v 'ALL:#SECLEVEL=2'
Ok, so the problem was that I was generating all of the files on my test PC, and then sending it to the server.
I've tried generating everything on the server, and then copying appropriate files to my test PC, and everything works fine.
I've followed http://rockingdlabs.dunmire.org/exercises-experiments/ssl-client-certs-to-secure-mqtt . With lesser changes like hostname etc.
I had the same issue.
To fix it, while generating server.crt, answer to question 'Common Name' with IP address of the machine where Mqtt broker is going to be run.
I'm trying to configure Titanium web proxy to use my own SSL certificate (ok and I need to generate my certificate(s) again because i just deleted them).
First: my use case works fine, I need to intercept https traffic and
I setup Titanium in a .NET Core app. It generated and
configured/installed come "rootCert.pfx" file and I can intercept
https traffic.
ref: https://github.com/justcoding121/Titanium-Web-Proxy/wiki#custom-root-certificates
The referenced page says I can set a custom root certificate using the RootCertificate property on the proxyserver.
So I create a certificate:
openssl req -x509 -sha256 -nodes -newkey rsa:2048 -days 365 -keyout localhost.key -out localhost.crt
convert it to a pfx:
openssl pkcs12 -export -out localhost.pfx -inkey localhost.key -in localhost.crt
copy it to the output directory and configure it as RootCertificate.
But now my browser says for any https request:
ERR_CONNECTION_CLOSED
I tried doubleclicking and installing the crt file but this doesn't help..
Am a little lost here as to where I should place what certificate. To make things more complicated for me to understand there is also a GenericCertificate property on the ExplicitProxyEndPoint class... If I configure the root certificate there then my browser returns:
ERR_CERT_AUTHORITY_INVALID
Any guidance or tips would be greatly appreciated!
Second try (spoiler: failed again)
Create CA key: customCA.key
openssl genrsa -des3 -out customCA.key 2048
Create CA root certificate: customCA.pem
openssl req -x509 -new -nodes -key customCA.key -sha256 -days 1825 -out customCA.pem
Trust CA root certificate: Import customCA.pem
Create localhost key: localhost.key
openssl genrsa -out localhost.key 2048
Create localhost sign request: localhost.csr
openssl req -new -key localhost.key -out localhost.csr
Create custom ext options: localhost.ext
[ req ]
default_bits = 2048
default_keyfile = customCA.pem
distinguished_name = req_distinguished_name
req_extensions = v3_req
x509_extensions = v3_ca
[req_distinguished_name]
C = [Press Enter to Continue]
C_default = US
C_min = 2
C_max = 2
O = [Press Enter to Continue]
O_default = default
0.OU=[Press Enter to Continue]
0.OU_default = default
1.OU=[Press Enter to Continue]
1.OU_default = PKI
2.OU=[Press Enter to Continue]
2.OU_default = ABCD
commonName = Public FQDN of server
commonName_max = 64
emailAddress = [Press Enter to Continue]
emailAddress_default = myEmail#email.com
[ v3_req ]
basicConstraints = CA:TRUE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment
[ v3_ca ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer:always
subjectAltName = email:myEmail#email.com
issuerAltName = issuer:copy
Create signed localhost certificate: localhost.crt
openssl x509 -req -in localhost.csr -CA customCA.pem -CAkey customCA.key -CAcreateserial -out localhost.crt -days 1825 -sha256 -extfile localhost.ext
Convert signed localhost certificate from crt to pfx: localhost.pfx
openssl pkcs12 -export -out localhost.pfx -inkey localhost.key -in localhost.crt
Now if I specify localhost.pfx as the RootCertificate for the proxyserver (which i'm assuming will be trusted due to the fact that it is signed by customCA which is a trusted authority) i still get:
ERR_CONNECTION_CLOSED
I'm starting to get confused about RootCertificate and Certificate Authority. It seems that the proxyserver requires a mix of both?
Does anyone have a handy script to generate SSL certificates such that it generates the CA certificate and the server certificate. More importantly, create it in a way that I can import the CA certificate into my trusted root list (of my windows system) so that the browser does not flag the site as untrusted.
I used the following script to do it but I am not able to persuade my browser to trust the certificate.
I'd greatly appreciate any help here.
# Generate a private key
openssl genrsa -des3 -out server.key 1024
# Generate a CSR (Certificate Signing Request)
openssl req -new -key server.key -out server.csr
# Remove Passphrase from Key
cp server.key server.key.org
openssl rsa -in server.key.org -out server.key
# Generating a Self-Signed Certificate
openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt
Regards,
Kashyap
Your script is only generating one certificate, a self-signed certificate. Usually, the self-signed certificate is called the Root certificate. This can be used as a CA certificate, but often an intermediate CA certificate is created and signed by the Root private key. This intermediate CA certificate is then used to sign Server certificates. So you have this hierarchy:
Root -> CA -> Server
The CA and Root cert can go into the trusted certificate list. Then a browser that trusts that list will also trust any certificate signed by the CA or Root entities.
You don't have to have this hierarchy...you can use the Root certificate as the CA and skip the middle cert. You can also just use 1 self-signed certificate as the Root/Server certificate. See this article (Trusting self-signed certificates).
But assuming you do have this hierarchy, here are some OpenSSL commands to generate the necessary keys and certificates:
# 1. Create Root private key
openssl genrsa -out root.key 2048
# 2. Create self-signed Root certificate
openssl req -new -key root.key -x509 -out root.crt -days 5000 -sha256
# 3. Create CA private key
openssl genrsa -out ca.key 2048
# 4. Create CA CSR
openssl req -new -key ca.key -out ca.csr -days 5000
# 5. Sign and create CA certificate
openssl x509 -req -in ca.csr -CA root.crt -CAkey root.key -out ca.crt -set_serial 2 -days 5000 -sha256
# 6. Create Server private key
openssl genrsa -out server.key 2048
# 7. Create Server CSR
openssl req -new -key server.key -out server.csr -days 5000
# 8. Sign and create Server certificate
openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -out server.crt -set_serial 3 -days 5000 -sha256
Change the key bits, # of valid days, serial numbers, and add V3 extensions as you see fit.
Also remember that different browsers have different lists that they trust. Chrome and IE use the Windows default list. Firefox has its own list.
Do you have a trusted CA certificate?
You are generating a self-signed certificate which is always considered as untrusted by browsers.