i've created my own CA and intermediate CA with openssl.
On my Zyxel AP i've created an csr.
I signed the csr through my intermediate CA and imported the server
cert to my zyxel AP.
I've also uploaded the fullchain root CA (CA and Intermediate) to my zyxel AP.
I'm using ubuntu so i've installed fullchain CA in my cerstore (/usr/local/share/ca-certificates | update update-ca-certificates)
I also imported the fullchain CA in my Browser Cert Store (tested with firefox, brave)....
But when i now call up the webgui from my AP i get the follwing message:
SSL_ERROR_BAD_CERT_DOMAIN
This happens for all browsers.
When i check with curl or openssl, everything looks good:
curl -vvI https://zyxel.home.arpa
ALPN: offers h2
* ALPN: offers http/1.1
* CAfile: /etc/ssl/certs/ca-certificates.crt
* CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_CHACHA20_POLY1305_SHA256
.
.
.
SSL certificate verify ok.
openssl s_client -CAfile ca-chain-bundle.cert.pem https://zyxel.home.arpa
New, TLSv1.3, Cipher is TLS_CHACHA20_POLY1305_SHA256
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
What can i try to fix this browser issue?
Edit 1:
without CAfile:
openssl s_client -connect zyxel.home.arpa:443
.
.
verify error:num=20:unable to get local issuer certificate
.
verify error:num=21:unable to verify the first certificate
.
Edit 2:
# President James K. Polk, here are the output of the server crt:
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 37:5b:25:e6:31:1b:7e:f7:63:14:30:e1:b6:ca:d2:11:a2:83:44:1c
Signature Algorithm: sha256WithRSAEncryption
Issuer: C = DE, ST = Home, O = Home Inc., CN = Home Intermediate-CA, emailAddress = admin#home.sh
Validity
Not Before: Nov 22 20:20:47 2022 GMT
Not After : Nov 22 20:20:47 2023 GMT
Subject: CN = zyxel.home.arpa, C = DE, ST = Home, L = Home, O = Home Inc, OU = IT
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:aa:be:cf:97:ad:fd:da:1a:9b:c4:af:9a:07:ac:
b7:08:bb:e3:eb:b8:d0:dc:fc:34:bf:8c:c8:5b:3f:
37:a7:20:7d:7e:eb:c9:e1:ce:c6:a8:84:2a:a3:35:
74:83:c9:62:94:ad:92:5b:c5:54:99:9e:14:c9:2b:
73:44:75:06:de:d4:dc:13:a6:0c:8c:b6:d9:84:e2:
1e:51:f8:2f:83:3c:62:95:ca:32:39:07:2b:81:41:
f9:88:08:95:fb:f9:c2:10:f0:de:25:b6:e2:83:f0:
f2:86:41:7d:5d:09:91:3b:04:b8:5f:74:b7:f5:2e:
e8:fa:9b:f5:17:a7:ef:d1:45:ed:05:8e:f3:8e:c3:
a1:96:42:9d:dd:ef:2f:03:81:97:b9:c5:df:9c:41:
3b:b6:9d:7b:09:a0:bf:ad:e8:6a:e2:05:ef:2b:fc:
67:4d:5a:dd:a4:ba:7b:58:a8:65:53:08:06:60:00:
08:85:12:34:31:9b:93:27:d2:35:75:00:f0:01:f5:
58:7f:1a:e5:1f:e5:08:8a:14:ca:c4:17:4d:90:ec:
30:7a:38:3e:ad:90:db:08:46:35:c4:6e:a7:8e:81:
77:eb:15:47:50:7e:d1:71:d5:09:38:64:c3:fa:08:
2a:31:a0:bd:87:0b:70:27:b3:42:fe:20:de:b1:be:
87:a9
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Cert Type:
SSL Server
Netscape Comment:
OpenSSL Generated Server Certificate
X509v3 Subject Key Identifier:
F5:D6:9B:95:CA:2C:8E:41:92:5F:3E:3E:9C:D5:31:CE:6A:D0:F8:95
X509v3 Authority Key Identifier:
keyid:25:0C:ED:3A:E1:A0:B9:86:A0:FB:43:9F:20:F0:F4:C0:5E:85:C4:D7
DirName:/C=DE/ST=Home/L=Home/O=Home Inc./CN=Home Root-CA/emailAddress=admin#home.sh
serial:01
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication
and here's the output ofthe generated csr on the zyxel AP:
Certificate Request:
Data:
Version: 1 (0x0)
Subject: CN = zyxel.home.arpa, C = DE, ST = Home, L = Home, O = Home Inc, OU = IT
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:aa:be:cf:97:ad:fd:da:1a:9b:c4:af:9a:07:ac:
b7:08:bb:e3:eb:b8:d0:dc:fc:34:bf:8c:c8:5b:3f:
37:a7:20:7d:7e:eb:c9:e1:ce:c6:a8:84:2a:a3:35:
74:83:c9:62:94:ad:92:5b:c5:54:99:9e:14:c9:2b:
73:44:75:06:de:d4:dc:13:a6:0c:8c:b6:d9:84:e2:
1e:51:f8:2f:83:3c:62:95:ca:32:39:07:2b:81:41:
f9:88:08:95:fb:f9:c2:10:f0:de:25:b6:e2:83:f0:
f2:86:41:7d:5d:09:91:3b:04:b8:5f:74:b7:f5:2e:
e8:fa:9b:f5:17:a7:ef:d1:45:ed:05:8e:f3:8e:c3:
a1:96:42:9d:dd:ef:2f:03:81:97:b9:c5:df:9c:41:
3b:b6:9d:7b:09:a0:bf:ad:e8:6a:e2:05:ef:2b:fc:
67:4d:5a:dd:a4:ba:7b:58:a8:65:53:08:06:60:00:
08:85:12:34:31:9b:93:27:d2:35:75:00:f0:01:f5:
58:7f:1a:e5:1f:e5:08:8a:14:ca:c4:17:4d:90:ec:
30:7a:38:3e:ad:90:db:08:46:35:c4:6e:a7:8e:81:
77:eb:15:47:50:7e:d1:71:d5:09:38:64:c3:fa:08:
2a:31:a0:bd:87:0b:70:27:b3:42:fe:20:de:b1:be:
87:a9
Exponent: 65537 (0x10001)
Attributes:
Netscape Comment :OpenSSL Generated Certificate
Requested Extensions:
X509v3 Subject Key Identifier:
F5:D6:9B:95:CA:2C:8E:41:92:5F:3E:3E:9C:D5:31:CE:6A:D0:F8:95
X509v3 Key Usage: critical
Digital Signature, Key Encipherment, Data Encipherment, Certificate Sign
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Server Authentication
X509v3 Subject Alternative Name:
othername: UPN::zyxel.home.arpa, DNS:zyxel.home.arpa
Signature Algorithm: sha512WithRSAEncryption
Signature Value:
1b:04:05:e6:02:89:4d:1d:67:a4:bb:15:06:20:93:58:c3:2b:
72:3c:e0:39:cd:f0:ea:6e:3a:db:33:02:3e:fa:ca:67:ec:e4:
58:a5:cf:ad:c0:51:b1:bb:0d:22:3f:a5:fc:ac:d1:e9:90:d6:
71:71:5d:dc:56:f1:14:21:cb:a3:53:be:0a:32:43:8f:8a:74:
55:08:e3:1d:44:7d:72:f3:94:7f:1a:99:71:b7:97:be:a6:ff:
a8:cf:95:f5:3b:c3:c6:6c:e3:ef:d9:39:8d:03:17:2e:15:2c:
92:ee:00:88:5f:23:21:a4:ac:27:c6:66:00:a5:5d:89:8d:f3:
87:43:34:35:16:e4:bd:72:38:ba:2c:27:f4:c9:08:22:aa:86:
21:6c:98:9f:4b:2b:7e:5e:6a:aa:5c:19:80:29:32:6d:4f:78:
1d:db:5b:1d:a1:bc:31:86:e9:65:af:ee:30:35:12:ce:d4:18:
b1:06:57:e3:da:f6:63:b0:48:53:64:0a:4b:ca:2a:20:d6:5d:
90:1a:bf:af:bb:d3:18:e8:5e:42:2f:3f:c8:96:20:63:66:9e:
2e:b1:2a:fa:82:f6:ba:d0:d3:7f:e7:a5:5d:f5:3a:fb:a9:b0:
54:a5:0a:14:48:8a:37:1e:e8:32:6c:73:7d:4c:af:dc:21:bc:
24:60:9e:2c
Solution:
i forgot to add the Subject Alt Name part into my openssl.cnf (thanks for the hint President James K. Polk):
basicConstraints = CA:FALSE
nsCertType = server
nsComment = "OpenSSL Generated Server Certificate"
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer:always
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth
subjectAltName = #alt_names
[alt_names]
IP.1 = IP
DNS.1 = DNS NAME
Related
I have a barebone simple example that works locally but not in Azure. My original question was a bit specific to an cors-error, that i have now worked around, and therefor edited away that part. But i still cant manage to make WS work on azure. And i need help.;
var server = http.Server(app);
const wss = new WebSocket.Server({server});
server.listen(8070, () => {
console.log("Listening on " + port)
});
wss.on('connection', (socket) => {
console.log('a user connected');
socket.on('message', (msg) => {
console.log(msg)
socket.send(JSON.stringify({hey:'you'}))
})
});
client connection-string:
SOCKET_ENDPOINT = 'wss://******.azurewebsites.net/';
I've turned on websockets in my app-configuration.
EDIT:
So i have now turned every stone. Even switched library from socket.io to ws. Same problem. I came a little further i think when trying different things, now i get following error "Firefox can’t establish a connection to the server at wss://*******.azurewebsites.net:8070/."
Edit2:
The http-upgrade is fine
Here's the error
Edit 3: Curl command:
* TCP_NODELAY set
* Connected to *******.azurewebsites.net (20.40.202.6) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
* subject: CN=*.azurewebsites.net
* start date: Sep 28 19:00:01 2020 GMT
* expire date: Sep 28 19:00:01 2021 GMT
* subjectAltName: host "********.azurewebsites.net" matched cert's "*.azurewebsites.net"
* issuer: C=US; O=Microsoft Corporation; CN=Microsoft RSA TLS CA 01
* SSL certificate verify ok.
> GET /socket.io/?EIO=4 HTTP/1.1
> Host: *********.azurewebsites.net
> User-Agent: curl/7.68.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 401 Unauthorized
< Server: Kestrel
< WWW-Authenticate: Bearer realm="********.azurewebsites.net" authorization_uri="https://login.windows.net/<tenant>/oauth2/authorize" resource_id="<resource>"
< Date: Tue, 22 Jun 2021 05:56:15 GMT
< Content-Length: 0
<
* Connection #0 to host *******.azurewebsites.net left intact
I am guessing that you host your app in Azure AppService?
Make sure you have websocket option turned on in platform:
AppService resource -> Settings -> General settings tab -> Platform settings section
Cloud Provider: Azure
Istio Version: 1.19
Kubernetes Version: 1.12.8
Below is my Virtual Service and Gateway yaml
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: app-ingress-rules
namespace: istio-system
# Define the routes less restrictive first to more restrictive. this file gets read from bottom to top.
spec:
# https://istio.io/docs/reference/config/istio.networking.v1alpha3/#VirtualService
gateways: # The default `mesh` value for when left blank is doesn't seem to propigate the rule properly. For now, always use a list of FQDN gateways
- tls-gateway
hosts:
- "dev.myapp.westus.cld.something.com" # This host is part of installed HTTPS cert
- "nonprod.westus.cloudapp.azure.com" # This host is NOT part of installed HTTPS cert
http:
# Routes
- match:
- uri:
prefix: /myapp/status
rewrite:
uri: /status
route:
- destination:
host: myapp.myapp-ns.svc.cluster.local
--------------------------------------------
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: tls-gateway
namespace: istio-system
spec:
selector:
istio: ingressgateway
servers:
- port:
name: https
number: 443
protocol: HTTPS
tls:
mode: SIMPLE
serverCertificate: /etc/istio/ingressgateway-certs/tls.crt
privateKey: /etc/istio/ingressgateway-certs/tls.key
hosts:
- "*"
If I do
curl -Iv https://dev.myapp.westus.cld.something.com/myapp/status
I get HTTP 404 as below
* Trying 123.12.123.12...
* TCP_NODELAY set
* Connected to dev.myapp.westus.cld.something.com (123.12.123.12.) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:#STRENGTH
* successfully set certificate verify locations:
* CAfile: /etc/ssl/cert.pem
CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-CHACHA20-POLY1305
* ALPN, server accepted to use h2
* Server certificate:
* subject: C=US; ST=***; L=*****; O=******, Inc.; CN=*********
* start date: Jul 26 20:32:59 2019 GMT
* expire date: Jul 26 20:32:59 2021 GM
* subjectAltName: host "dev.myapp.westus.cld.something.com" matched cert's "dev.myapp.westus.cld.something.com"
* issuer: C=BE; O=GlobalSign nv-sa; CN=GlobalSign RSA OV SSL CA 2018
* SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x7f995e006600)
> HEAD /myapp/status HTTP/2
> Host: dev.myapp.westus.cld.something.com
> User-Agent: curl/7.54.0
> Accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
< HTTP/2 404
HTTP/2 404
< location: https://dev.myapp.westus.cld.something.com/myapp/status
location: https://dev.myapp.westus.cld.something.com /myapp/status
< date: Wed, 31 Jul 2019 19:10:13 GMT
date: Wed, 31 Jul 2019 19:10:13 GMT
< server: istio-envoy
server: istio-envoy
<
* Connection #0 to host dev.myapp.westus.cld.something.com left intact
However when I try with
curl -Iv --insecure https://nonprod.westus.cloudapp.azure.com/myapp/status
I get HTTP 200. see below
* Trying 123.12.123.12...
* TCP_NODELAY set
* Connected to nonprod.westus.cloudapp.azure.com (123.12.123.12) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection:
ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:#STRENGTH
* successfully set certificate verify locations:
* CAfile: /etc/ssl/cert.pem
CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-CHACHA20-POLY1305
* ALPN, server accepted to use h2
* Server certificate:
* subject: C=US; ST=****; L=*****; O=******, Inc.; CN=*********
* start date: Jul 26 20:32:59 2019 GMT
* expire date: Jul 26 20:32:59 2021 GMT
* issuer: C=BE; O=GlobalSign nv-sa; CN=GlobalSign RSA OV SSL CA 2018
* SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x7fb4b7003c00)
> HEAD /myapp/status HTTP/2
> Host: nonprod.westus.cloudapp.azure.com
> User-Agent: curl/7.54.0
> Accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
< HTTP/2 200
HTTP/2 200
< request-context: appId=cid-v1:39296fe8-1dc6-4049-bb31-e7816e83b9ec
request-context: appId=cid-v1:39296fe8-1dc6-4049-bb31-e7816e83b9ec
< access-control-allow-origin: *
access-control-allow-origin: *
< access-control-expose-headers: Content-Disposition
access-control-expose-headers: Content-Disposition
< content-type: text/plain;charset=ISO-8859-1
content-type: text/plain;charset=ISO-8859-1
< content-length: 69
content-length: 69
< date: Wed, 31 Jul 2019 19:07:54 GMT
date: Wed, 31 Jul 2019 19:07:54 GMT
< x-envoy-upstream-service-time: 7
x-envoy-upstream-service-time: 7
< server: istio-envoy
server: istio-envoy
<
* Connection #0 to host nonprod.westus.cloudapp.azure.com left intact
Is my VS configuration wrong with regards to accepting HTTPS traffic? I am unable to look at envoy logs to see if there is any error.
How can I pinpoint where the issue is?
Update
dev.myapp.westus.cld.something.com is a CName record which ultimately points to nonprod.westus.cloudapp.azure.com
nonprod.westus.cloudapp.azure.com is a actual DNS which is mapped to a public IP.
Note sure if that makes any difference.
During my search, I found several ways of signing a SSL Certificate Signing Request:
Using the x509 module:
openssl x509 -req -days 360 -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out server.crt
Using the ca module:
openssl ca -cert ca.crt -keyfile ca.key -in server.csr -out server.crt
Note: I am unsure of the use of the right parameters for this one. Please advise correct usage if I am to use it.
What way should one use to sign certificate requests with your Certification Authority?
Is one method better than the other (for example, one being deprecated)?
1. Using the x509 module
openssl x509 ...
...
2 Using the ca module
openssl ca ...
...
You are missing the prelude to those commands.
This is a two-step process. First you set up your CA, and then you sign an end entity certificate (a.k.a server or user). Both of the two commands elide the two steps into one. And both assume you have a an OpenSSL configuration file already setup for both CAs and Server (end entity) certificates.
First, create a basic configuration file:
$ touch openssl-ca.cnf
Then, add the following to it:
HOME = .
RANDFILE = $ENV::HOME/.rnd
####################################################################
[ ca ]
default_ca = CA_default # The default ca section
[ CA_default ]
default_days = 365 # How long to certify for
default_crl_days = 30 # How long before next CRL
default_md = sha256 # Use public key default MD
preserve = no # Keep passed DN ordering
x509_extensions = ca_extensions # The extensions to add to the cert
email_in_dn = no # Don't concat the email in the DN
copy_extensions = copy # Required to copy SANs from CSR to cert
####################################################################
[ req ]
default_bits = 4096
default_keyfile = cakey.pem
distinguished_name = ca_distinguished_name
x509_extensions = ca_extensions
string_mask = utf8only
####################################################################
[ ca_distinguished_name ]
countryName = Country Name (2 letter code)
countryName_default = US
stateOrProvinceName = State or Province Name (full name)
stateOrProvinceName_default = Maryland
localityName = Locality Name (eg, city)
localityName_default = Baltimore
organizationName = Organization Name (eg, company)
organizationName_default = Test CA, Limited
organizationalUnitName = Organizational Unit (eg, division)
organizationalUnitName_default = Server Research Department
commonName = Common Name (e.g. server FQDN or YOUR name)
commonName_default = Test CA
emailAddress = Email Address
emailAddress_default = test#example.com
####################################################################
[ ca_extensions ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always, issuer
basicConstraints = critical, CA:true
keyUsage = keyCertSign, cRLSign
The fields above are taken from a more complex openssl.cnf (you can find it in /usr/lib/openssl.cnf), but I think they are the essentials for creating the CA certificate and private key.
Tweak the fields above to suit your taste. The defaults save you the time from entering the same information while experimenting with configuration file and command options.
I omitted the CRL-relevant stuff, but your CA operations should have them. See openssl.cnf and the related crl_ext section.
Then, execute the following. The -nodes omits the password or passphrase so you can examine the certificate. It's a really bad idea to omit the password or passphrase.
$ openssl req -x509 -config openssl-ca.cnf -days 365 -newkey rsa:4096 -sha256 -nodes -out cacert.pem -outform PEM
After the command executes, cacert.pem will be your certificate for CA operations, and cakey.pem will be the private key. Recall the private key does not have a password or passphrase.
You can dump the certificate with the following.
$ openssl x509 -in cacert.pem -text -noout
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 11485830970703032316 (0x9f65de69ceef2ffc)
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, ST=MD, L=Baltimore, CN=Test CA/emailAddress=test#example.com
Validity
Not Before: Jan 24 14:24:11 2014 GMT
Not After : Feb 23 14:24:11 2014 GMT
Subject: C=US, ST=MD, L=Baltimore, CN=Test CA/emailAddress=test#example.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (4096 bit)
Modulus:
00:b1:7f:29:be:78:02:b8:56:54:2d:2c:ec:ff:6d:
...
39:f9:1e:52:cb:8e:bf:8b:9e:a6:93:e1:22:09:8b:
59:05:9f
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
4A:9A:F3:10:9E:D7:CF:54:79:DE:46:75:7A:B0:D0:C1:0F:CF:C1:8A
X509v3 Authority Key Identifier:
keyid:4A:9A:F3:10:9E:D7:CF:54:79:DE:46:75:7A:B0:D0:C1:0F:CF:C1:8A
X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Key Usage:
Certificate Sign, CRL Sign
Signature Algorithm: sha256WithRSAEncryption
4a:6f:1f:ac:fd:fb:1e:a4:6d:08:eb:f5:af:f6:1e:48:a5:c7:
...
cd:c6:ac:30:f9:15:83:41:c1:d1:20:fa:85:e7:4f:35:8f:b5:
38:ff:fd:55:68:2c:3e:37
And test its purpose with the following (don't worry about the Any Purpose: Yes; see "critical,CA:FALSE" but "Any Purpose CA : Yes").
$ openssl x509 -purpose -in cacert.pem -inform PEM
Certificate purposes:
SSL client : No
SSL client CA : Yes
SSL server : No
SSL server CA : Yes
Netscape SSL server : No
Netscape SSL server CA : Yes
S/MIME signing : No
S/MIME signing CA : Yes
S/MIME encryption : No
S/MIME encryption CA : Yes
CRL signing : Yes
CRL signing CA : Yes
Any Purpose : Yes
Any Purpose CA : Yes
OCSP helper : Yes
OCSP helper CA : Yes
Time Stamp signing : No
Time Stamp signing CA : Yes
-----BEGIN CERTIFICATE-----
MIIFpTCCA42gAwIBAgIJAJ9l3mnO7y/8MA0GCSqGSIb3DQEBCwUAMGExCzAJBgNV
...
aQUtFrV4hpmJUaQZ7ySr/RjCb4KYkQpTkOtKJOU1Ic3GrDD5FYNBwdEg+oXnTzWP
tTj//VVoLD43
-----END CERTIFICATE-----
For part two, I'm going to create another configuration file that's easily digestible. First, touch the openssl-server.cnf (you can make one of these for user certificates also).
$ touch openssl-server.cnf
Then open it, and add the following.
HOME = .
RANDFILE = $ENV::HOME/.rnd
####################################################################
[ req ]
default_bits = 2048
default_keyfile = serverkey.pem
distinguished_name = server_distinguished_name
req_extensions = server_req_extensions
string_mask = utf8only
####################################################################
[ server_distinguished_name ]
countryName = Country Name (2 letter code)
countryName_default = US
stateOrProvinceName = State or Province Name (full name)
stateOrProvinceName_default = MD
localityName = Locality Name (eg, city)
localityName_default = Baltimore
organizationName = Organization Name (eg, company)
organizationName_default = Test Server, Limited
commonName = Common Name (e.g. server FQDN or YOUR name)
commonName_default = Test Server
emailAddress = Email Address
emailAddress_default = test#example.com
####################################################################
[ server_req_extensions ]
subjectKeyIdentifier = hash
basicConstraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment
subjectAltName = #alternate_names
nsComment = "OpenSSL Generated Certificate"
####################################################################
[ alternate_names ]
DNS.1 = example.com
DNS.2 = www.example.com
DNS.3 = mail.example.com
DNS.4 = ftp.example.com
If you are developing and need to use your workstation as a server, then 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
Then, create the server certificate request. Be sure to omit -x509*. Adding -x509 will create a certificate, and not a request.
$ openssl req -config openssl-server.cnf -newkey rsa:2048 -sha256 -nodes -out servercert.csr -outform PEM
After this command executes, you will have a request in servercert.csr and a private key in serverkey.pem.
And you can inspect it again.
$ openssl req -text -noout -verify -in servercert.csr
Certificate:
verify OK
Certificate Request:
Version: 0 (0x0)
Subject: C=US, ST=MD, L=Baltimore, CN=Test Server/emailAddress=test#example.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:ce:3d:58:7f:a0:59:92:aa:7c:a0:82:dc:c9:6d:
...
f9:5e:0c:ba:84:eb:27:0d:d9:e7:22:5d:fe:e5:51:
86:e1
Exponent: 65537 (0x10001)
Attributes:
Requested Extensions:
X509v3 Subject Key Identifier:
1F:09:EF:79:9A:73:36:C1:80:52:60:2D:03:53:C7:B6:BD:63:3B:61
X509v3 Basic Constraints:
CA:FALSE
X509v3 Key Usage:
Digital Signature, Key Encipherment
X509v3 Subject Alternative Name:
DNS:example.com, DNS:www.example.com, DNS:mail.example.com, DNS:ftp.example.com
Netscape Comment:
OpenSSL Generated Certificate
Signature Algorithm: sha256WithRSAEncryption
6d:e8:d3:85:b3:88:d4:1a:80:9e:67:0d:37:46:db:4d:9a:81:
...
76:6a:22:0a:41:45:1f:e2:d6:e4:8f:a1:ca:de:e5:69:98:88:
a9:63:d0:a7
Next, you have to sign it with your CA.
You are almost ready to sign the server's certificate by your CA. The CA's openssl-ca.cnf needs two more sections before issuing the command.
First, open openssl-ca.cnf and add the following two sections.
####################################################################
[ signing_policy ]
countryName = optional
stateOrProvinceName = optional
localityName = optional
organizationName = optional
organizationalUnitName = optional
commonName = supplied
emailAddress = optional
####################################################################
[ signing_req ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
basicConstraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment
Second, add the following to the [ CA_default ] section of openssl-ca.cnf. I left them out earlier, because they can complicate things (they were unused at the time). Now you'll see how they are used, so hopefully they will make sense.
base_dir = .
certificate = $base_dir/cacert.pem # The CA certifcate
private_key = $base_dir/cakey.pem # The CA private key
new_certs_dir = $base_dir # Location for new certs after signing
database = $base_dir/index.txt # Database index file
serial = $base_dir/serial.txt # The current serial number
unique_subject = no # Set to 'no' to allow creation of
# several certificates with same subject.
Third, touch index.txt and serial.txt:
$ touch index.txt
$ echo '01' > serial.txt
Then, perform the following:
$ openssl ca -config openssl-ca.cnf -policy signing_policy -extensions signing_req -out servercert.pem -infiles servercert.csr
You should see similar to the following:
Using configuration from openssl-ca.cnf
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
countryName :PRINTABLE:'US'
stateOrProvinceName :ASN.1 12:'MD'
localityName :ASN.1 12:'Baltimore'
commonName :ASN.1 12:'Test CA'
emailAddress :IA5STRING:'test#example.com'
Certificate is to be certified until Oct 20 16:12:39 2016 GMT (1000 days)
Sign the certificate? [y/n]:Y
1 out of 1 certificate requests certified, commit? [y/n]Y
Write out database with 1 new entries
Data Base Updated
After the command executes, you will have a freshly minted server certificate in servercert.pem. The private key was created earlier and is available in serverkey.pem.
Finally, you can inspect your freshly minted certificate with the following:
$ openssl x509 -in servercert.pem -text -noout
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 9 (0x9)
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, ST=MD, L=Baltimore, CN=Test CA/emailAddress=test#example.com
Validity
Not Before: Jan 24 19:07:36 2014 GMT
Not After : Oct 20 19:07:36 2016 GMT
Subject: C=US, ST=MD, L=Baltimore, CN=Test Server
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:ce:3d:58:7f:a0:59:92:aa:7c:a0:82:dc:c9:6d:
...
f9:5e:0c:ba:84:eb:27:0d:d9:e7:22:5d:fe:e5:51:
86:e1
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
1F:09:EF:79:9A:73:36:C1:80:52:60:2D:03:53:C7:B6:BD:63:3B:61
X509v3 Authority Key Identifier:
keyid:42:15:F2:CA:9C:B1:BB:F5:4C:2C:66:27:DA:6D:2E:5F:BA:0F:C5:9E
X509v3 Basic Constraints:
CA:FALSE
X509v3 Key Usage:
Digital Signature, Key Encipherment
X509v3 Subject Alternative Name:
DNS:example.com, DNS:www.example.com, DNS:mail.example.com, DNS:ftp.example.com
Netscape Comment:
OpenSSL Generated Certificate
Signature Algorithm: sha256WithRSAEncryption
b1:40:f6:34:f4:38:c8:57:d4:b6:08:f7:e2:71:12:6b:0e:4a:
...
45:71:06:a9:86:b6:0f:6d:8d:e1:c5:97:8d:fd:59:43:e9:3c:
56:a5:eb:c8:7e:9f:6b:7a
Earlier, you added the following to CA_default: copy_extensions = copy. This copies extension provided by the person making the request.
If you omit copy_extensions = copy, then your server certificate will lack the Subject Alternate Names (SANs) like www.example.com and mail.example.com.
If you use copy_extensions = copy, but don't look over the request, then the requester might be able to trick you into signing something like a subordinate root (rather than a server or user certificate). Which means he/she will be able to mint certificates that chain back to your trusted root. Be sure to verify the request with openssl req -verify before signing.
If you omit unique_subject or set it to yes, then you will only be allowed to create one certificate under the subject's distinguished name.
unique_subject = yes # Set to 'no' to allow creation of
# several ctificates with same subject.
Trying to create a second certificate while experimenting will result in the following when signing your server's certificate with the CA's private key:
Sign the certificate? [y/n]:Y
failed to update database
TXT_DB error number 2
So unique_subject = no is perfect for testing.
If you want to ensure the Organizational Name is consistent between self-signed CAs, Subordinate CA and End-Entity certificates, then add the following to your CA configuration files:
[ policy_match ]
organizationName = match
If you want to allow the Organizational Name to change, then use:
[ policy_match ]
organizationName = supplied
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. RFC's 6797 and 7469 do not allow an IP address, either.
In addition to answer of #jww, I would like to say that the configuration in openssl-ca.cnf,
default_days = 1000 # How long to certify for
defines the default number of days the certificate signed by this root-ca will be valid. To set the validity of root-ca itself you should use '-days n' option in:
openssl req -x509 -days 3000 -config openssl-ca.cnf -newkey rsa:4096 -sha256 -nodes -out cacert.pem -outform PEM
Failing to do so, your root-ca will be valid for only the default one month and any certificate signed by this root CA will also have validity of one month.
Sometimes, such as for testing, you just want a simplistic means of generating a signed certificate, without setting up a full-blown CA configuration. This is possible using just the openssl req and openssl x509 commands. You would never use this method for production certificates, but since it is useful for some non-production situations, here are the commands.
Generate a self-signed signing certificate
First, create a self-signed certificate that will be used as the root of trust:
openssl req -x509 -days 365 -key ca_private_key.pem -out ca_cert.pem
Or equivalently, if you want to generate a private key and a self-signed certificate in a single command:
openssl req -x509 -days 365 -newkey rsa:4096 -keyout ca_private_key.pem -out ca_cert.pem
Generate a certificate request
Next, create a certificate request for the certificate to be signed:
openssl req -new -key my_private_key.pem -out my_cert_req.pem
Again, you may generate the private key and the request simultaneously, if needed:
openssl req -new -newkey rsa:4096 -keyout my_private_key.pem -out my_cert_req.pem
Generate a signed certificate
Finally, use the self-signed signing certificate to generate a signed certificate from the certificate request:
openssl x509 -req -in my_cert_req.pem -days 365 -CA ca_cert.pem -CAkey ca_private_key.pem -CAcreateserial -out my_signed_cert.pem
I've found a convenient script sscg for this task - https://github.com/sgallagher/sscg
Here is an example for Fedora linux:
Installation:
sudo yum install sscg
Example:
sscg \
--ca-key-password-prompt \
--lifetime=3650 \
--country=XX \
--state=myState \
--locality=myCity \
--organization=myOrg \
--organizational-unit=myUnit \
--email=myemail#example.com \
--hostname=foo.example.com \
--subject-alt-name=*.example.com \
--ca-key-file=CA.key \
--ca-file=CA.pem \
--cert-key-file=foo.example.com.key \
--cert-file=foo.example.com.pem
I try to only use 256bit cipher suites only with following setup:
const https = require('https');
const fs = require('fs');
const constants = require('constants');
const serverKey = 'server.key';
const serverCrt = 'server.crt';
httpsOptions = {
key: fs.readFileSync(serverKey),
cert: fs.readFileSync(serverCrt),
secureOptions: constants.SSL_OP_NO_TLSv1 | constants.SSL_OP_NO_TLSv1_1,
ciphers: [
'ECDHE-ECDSA-AES256-GCM-SHA384',
'ECDHE-RSA-AES256-GCM-SHA384',
"HIGH",
"!aNULL",
"!eNULL",
"!EXPORT",
"!DES",
"!RC4",
"!MD5",
"!PSK",
"!SRP",
"!CAMELLIA"
].join(':')
};
https.createServer(httpsOptions, (req, res) => {
res.writeHead(200);
res.end('hello world\n');
}).listen(8000);
However sslscan and ssllabs.com (my blog is using the same httpsOptions) testing show I still have
128bit ciphers
NON-GCM ciphers
Following is out put from sslscan:
[23:13:03]JS#JS-Mac-mini ~> sslscan localhost:8000
Version: 1.11.8
OpenSSL 1.0.2k 26 Jan 2017
OpenSSL version does not support SSLv2
SSLv2 ciphers will not be detected
Testing SSL server localhost on port 8000
TLS Fallback SCSV:
Server supports TLS Fallback SCSV
TLS renegotiation:
Session renegotiation not supported
TLS Compression:
Compression disabled
Heartbleed:
TLS 1.2 not vulnerable to heartbleed
TLS 1.1 not vulnerable to heartbleed
TLS 1.0 not vulnerable to heartbleed
Supported Server Cipher(s):
Preferred TLSv1.2 256 bits ECDHE-RSA-AES256-GCM-SHA384 Curve P-256 DHE 256
Accepted TLSv1.2 256 bits ECDHE-RSA-AES256-SHA384 Curve P-256 DHE 256
Accepted TLSv1.2 256 bits ECDHE-RSA-AES256-SHA Curve P-256 DHE 256
Accepted TLSv1.2 256 bits AES256-GCM-SHA384
Accepted TLSv1.2 256 bits AES256-SHA256
Accepted TLSv1.2 256 bits AES256-SHA
Accepted TLSv1.2 128 bits ECDHE-RSA-AES128-GCM-SHA256 Curve P-256 DHE 256
Accepted TLSv1.2 128 bits ECDHE-RSA-AES128-SHA256 Curve P-256 DHE 256
Accepted TLSv1.2 128 bits ECDHE-RSA-AES128-SHA Curve P-256 DHE 256
Accepted TLSv1.2 128 bits AES128-GCM-SHA256
Accepted TLSv1.2 128 bits AES128-SHA256
Accepted TLSv1.2 128 bits AES128-SHA
SSL Certificate:
Signature Algorithm: sha256WithRSAEncryption
RSA Key Strength: 2048
Subject: localhost
Issuer: localhost
Not valid before: Jun 13 19:06:29 2016 GMT
Not valid after: Jun 13 19:06:29 2017 GMT
I expect to see only the following ciphers:
Preferred TLSv1.2 256 bits ECDHE-RSA-AES256-GCM-SHA384 Curve P-256 DHE 256
You're including HIGH in your SSL cipher configuration, which includes all the ciphers that OpenSSL considers high strength (128bit or above), and then you're excluding some specific other groups of ciphers. Remove HIGH and you'll just get the ciphers you want.
You can see what's in each group in OpenSSL from the command line with $ openssl ciphers -v HIGH
Alternatively you might just be able to specify the ciphers you want, and remove everything else.
add !AES128 to disable these 128bit ciphers.
sample:
ciphers: "ECDHE-RSA-AES256-GCM-SHA384:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!SRP:!CAMELLIA:HIGH:!AES128"
then supported ciphers will be:
Supported Server Cipher(s):
Accepted TLSv1 256 bits ECDHE-RSA-AES256-SHA
Accepted TLSv1 256 bits AES256-SHA
Accepted TLS11 256 bits ECDHE-RSA-AES256-SHA
Accepted TLS11 256 bits AES256-SHA
Accepted TLS12 256 bits ECDHE-RSA-AES256-GCM-SHA384
Accepted TLS12 256 bits ECDHE-RSA-AES256-SHA384
Accepted TLS12 256 bits ECDHE-RSA-AES256-SHA
Accepted TLS12 256 bits AES256-GCM-SHA384
Accepted TLS12 256 bits AES256-SHA256
Accepted TLS12 256 bits AES256-SHA
stack: nodejs4, chai,jdom. The objective is to write a test that interrogates the HTML of a URL in a web application which is only accessible over SSL in the corporate intranet.
I am writing a mocha test using jsdom and I get the SSL certificate error:
{ Error: unable to verify the first certificate
at Error (native)
at TLSSocket.<anonymous> (_tls_wrap.js:1060:38)
at emitNone (events.js:86:13)
at TLSSocket.emit (events.js:185:7)
at TLSSocket._finishInit (_tls_wrap.js:584:8)
at TLSWrap.ssl.onhandshakedone (_tls_wrap.js:416:38)
code: 'UNABLE_TO_VERIFY_LEAF_SIGNATURE' }
I have the following test code:
var chai = require('chai');
var jsdom = require('jsdom');
var expect = chai.expect;
https = require('https');
fs = require('fs');
var cas = require('ssl-root-cas/latest').inject().addFile('test/ssl/key.pem').addFile('test/ssl/server.crt');
//process.env.NODE_TLS_REJECT_UNAUTHORIZED = "0";
https.globalAgent.options.ca = cas;
jsdom.env(
"https://www.example.com",
['https://www.example.com/jquery-1.10.2.js'],
function(err, window) {
if(err){
console.log(err);
} else {
console.log("contents of the research project input box is:", window.$("#field_cell_1840 input.custom-combobox-input").text());
}
}
);
I have generated the keys in test/ssl like this:
openssl req -newkey rsa:2048 -new -nodes -keyout key.pem -out csr.pem
openssl x509 -req -days 365 -in csr.pem -signkey key.pem -out server.crt
I have followed various threads and tried suggestions in https://github.com/coolaj86/node-ssl-root-cas including bad ideas such as the use of process.env.NODE_TLS_REJECT_UNAUTHORIZED = "0"
When I do a curl -vk https://www.example.com then I get the following output:
ac2f15#UOS-012145 ~/git/NodeJS/test (master)
$ curl -vk https://www.example.com
* Rebuilt URL to: www.example.com
* timeout on name lookup is not supported
* Trying 192.168.168.116...
* Connected to www.example.com (192.168.168.116) port 443 (#0)
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:#STRENGTH
* successfully set certificate verify locations:
* CAfile: C:/Program Files/Git/mingw64/ssl/certs/ca-bundle.crt
CApath: none
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.0 (IN), TLS handshake, Server hello (2):
* TLSv1.0 (IN), TLS handshake, Certificate (11):
* TLSv1.0 (IN), TLS handshake, Server key exchange (12):
* TLSv1.0 (IN), TLS handshake, Server finished (14):
* TLSv1.0 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.0 (OUT), TLS change cipher, Client hello (1):
* TLSv1.0 (OUT), TLS handshake, Finished (20):
* TLSv1.0 (IN), TLS change cipher, Client hello (1):
* TLSv1.0 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.0 / DHE-RSA-AES256-SHA
* ALPN, server did not agree to a protocol
* Server certificate:
* subject: OU=Domain Control Validated; CN=sitepublisher-dev.soton.ac.uk
* start date: Dec 9 00:00:00 2014 GMT
* expire date: Dec 8 23:59:59 2017 GMT
* issuer: C=NL; ST=Noord-Holland; L=Amsterdam; O=TERENA; CN=TERENA SSL CA 2
* SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
> GET / HTTP/1.1
> Host: srv00700.soton.ac.uk
> User-Agent: curl/7.46.0
> Accept: */*
>
< HTTP/1.1 302 Found
< Date: Mon, 10 Oct 2016 16:09:05 GMT
< Server: Apache/2.2.22 (Unix) mod_ssl/2.2.22 OpenSSL/0.9.8e-fips-rhel5
< Location: https://www.example.com/
< Content-Length: 358
< Content-Type: text/html; charset=iso-8859-1
<
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
My question is, is there someone who has done a successful chai test using jdom on a https URL ? If so, could you please share your experience with me?