MongoDB Kubernetes connection failure with SSL - mongodb

I have three node MongoDB cluster in GCP kubernetes cluster following [1], [2]. I can properly connect with tls=false using mongosh client. Then I enabled tls following [3]. Mongo cluster start properly but I cannot connect from mongosh.
Following is the connection details.
{
"connectionString.standard": "mongodb://mongo-user:stl-m0ng0-dev#mongodb-dev-0.mongodb-dev-svc.dev.svc.cluster.local:27017,mongodb-dev-1.mongodb-dev-svc.dev.svc.cluster.local:27017,mongodb-dev-2.mongodb-dev-svc.dev.svc.cluster.local:27017/dev?replicaSet=mongodb-dev&ssl=true",
"connectionString.standardSrv": "mongodb+srv://mongo-user:stl-m0ng0-dev#mongodb-dev-svc.dev.svc.cluster.local/dev?replicaSet=mongodb-dev&ssl=true",
"password": "xxxxxxx",
"username": "mongo-user"
}
Followings are the certificate details.
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 2 (0x2)
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN = TLSGenSelfSignedtRootCA, L = $$$$
Validity
Not Before: Jul 27 09:07:50 2022 GMT
Not After : Jul 24 09:07:50 2032 GMT
Subject: CN = *.mongodb-dev-svc.dev.svc.cluster.local, O = client
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public-Key: (2048 bit)
Modulus:
00:c4:44:a6:21:95:85:9a:dc:96:63:8e:76:ed:d9:
3a:59
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
X509v3 Key Usage:
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Client Authentication
X509v3 Subject Alternative Name:
DNS:mongodb-dev-1.mongodb-dev-svc.dev.svc.cluster.local, DNS:mongodb-dev-2.mongodb-dev-svc.dev.svc.cluster.local, DNS:mongodb-dev-3.mongodb-dev-svc.dev.svc.cluster.local
Signature Algorithm: sha256WithRSAEncryption
7b:78:43:73:ae:2f:ce:97:de:b2:19:56:4c:38:71:8e:3d:ff:
5b:15:79:c1
Will display server certificate info
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1 (0x1)
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN = TLSGenSelfSignedtRootCA, L = $$$$
Validity
Not Before: Jul 27 09:07:50 2022 GMT
Not After : Jul 24 09:07:50 2032 GMT
Subject: CN = *.mongodb-dev-svc.dev.svc.cluster.local, O = server
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public-Key: (2048 bit)
Modulus:
00:bc:1e:4a:a7:4f:c4:01:71:2c:78:eb:ac:c9:53:
24:c1
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
X509v3 Key Usage:
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication
X509v3 Subject Alternative Name:
DNS:mongodb-dev-0.mongodb-dev-svc.dev.svc.cluster.local, DNS:mongodb-dev-1.mongodb-dev-svc.dev.svc.cluster.local, DNS:mongodb-dev-2.mongodb-dev-svc.dev.svc.cluster.local
Signature Algorithm: sha256WithRSAEncryption
16:0f:09:02:66:05:69:7b:91:3b:93:73:86:64:d5:8f:53:2d:
08:19:68:a7
Client side has following error
root#xxxxxxxxxxxxxxxxxx-55955c9fcd-bpp98:/usr/src/app# mongosh "mongodb+srv://mongo-user:stl-m0ng0-dev#mongodb-dev-svc.dev.svc.cluster.local/dev?replicaSet=mongodb-dev&ssl=false&tlsCAFile=ca.pem&tlsCertificateKeyFile=key.pem"
Current Mongosh Log ID: 62e1029487b960f1bd204b1d
Connecting to: mongodb+srv://<credentials>#mongodb-dev-svc.dev.svc.cluster.local/dev?replicaSet=mongodb-dev&ssl=false&tlsCAFile=ca.pem&tlsCertificateKeyFile=key.pem&appName=mongosh+1.5.1
MongoServerSelectionError: connection <monitor> to 10.120.6.8:27017 closed
Server side has following error
2022-07-27T09:25:44.992+0000 I NETWORK [conn25852] end connection 10.120.6.9:33914 (14 connections now open)
2022-07-27T09:25:44.993+0000 I NETWORK [listener] connection accepted from 10.120.6.9:33918 #25855 (15 connections now open)
2022-07-27T09:25:44.993+0000 E NETWORK [conn25854] SSL peer certificate validation failed: unsupported certificate purpose
2022-07-27T09:25:44.994+0000 I NETWORK [conn25854] Error receiving request from client: SSLHandshakeFailed: SSL peer certificate validation failed: unsupported certificate purpose. Ending connection from 10.120.8.127:58220 (connection id: 25854)
2022-07-27T09:25:44.994+0000 I NETWORK [conn25854] end connection 10.120.8.127:58220 (14 connections now open)
2022-07-27T09:25:44.995+0000 I NETWORK [listener] connection accepted from 10.120.8.127:58224 #25856 (15 connections now open)
2022-07-27T09:25:44.998+0000 E NETWORK [conn25855] SSL peer certificate validation failed: unsupported certificate purpose
2022-07-27T09:25:44.998+0000 I NETWORK [conn25855] Error receiving request from client: SSLHandshakeFailed: SSL peer certificate validation failed: unsupported certificate purpose. Ending connection from 10.120.6.9:33918 (connection id: 25855)
2022-07-27T09:25:44.998+0000 I NETWORK [conn25855] end connection 10.120.6.9:33918 (14 connections now open)
2022-07-27T09:25:45.000+0000 E NETWORK [conn25856] SSL peer certificate validation failed: unsupported certificate purpose
2022-07-27T09:25:45.000+0000 I NETWORK [conn25856] Error receiving request from client: SSLHandshakeFailed: SSL peer certificate validation failed: unsupported certificate purpose. Ending connection from 10.120.8.127:58224 (connection id: 25856)
2022-07-27T09:25:45.000+0000 I NETWORK [conn25856] end connection 10.120.8.127:58224 (13 connections now open)
2022-07-27T09:25:45.001+0000 I REPL_HB [replexec-2] Heartbeat to mongodb-dev-1.mongodb-dev-svc.dev.svc.cluster.local:27017 failed after 2 retries, response status: HostUnreachable: stream truncated
2022-07-27T09:25:45.003+0000 I NETWORK [listener] connection accepted from 10.120.8.127:58228 #25858 (14 connections now open)
2022-07-27T09:25:45.007+0000 E NETWORK [conn25858] SSL peer certificate validation failed: unsupported certificate purpose
2022-07-27T09:25:45.007+0000 I NETWORK [conn25858] Error receiving request from client: SSLHandshakeFailed: SSL peer certificate validation failed: unsupported certificate purpose. Ending connection from 10.120.8.127:58228 (connection id: 25858)
2022-07-27T09:25:45.007+0000 I NETWORK [conn25858] end connection 10.120.8.127:58228 (13 connections now open)
Operator log has TLS configuration issue.
2022-07-27T10:06:05.893Z INFO controllers/mongodb_status_options.go:110 TLS config is not yet valid, retrying in 10 seconds
2022-07-27T10:06:15.899Z INFO controllers/replica_set_controller.go:140 Reconciling MongoDB {"ReplicaSet": "dev/mongodb-replica-set"}
2022-07-27T10:06:15.900Z DEBUG controllers/replica_set_controller.go:142 Validating MongoDB.Spec {"ReplicaSet": "dev/mongodb-replica-set"}
2022-07-27T10:06:15.900Z DEBUG controllers/replica_set_controller.go:151 Ensuring the service exists {"ReplicaSet": "dev/mongodb-replica-set"}
2022-07-27T10:06:15.900Z DEBUG agent/agent_readiness.go:101 The Pod '' doesn't have annotation 'agent.mongodb.com/version' yet {"ReplicaSet": "dev/mongodb-replica-set"}
2022-07-27T10:06:15.900Z DEBUG agent/agent_readiness.go:101 The Pod '' doesn't have annotation 'agent.mongodb.com/version' yet {"ReplicaSet": "dev/mongodb-replica-set"}
2022-07-27T10:06:15.900Z DEBUG agent/agent_readiness.go:101 The Pod '' doesn't have annotation 'agent.mongodb.com/version' yet {"ReplicaSet": "dev/mongodb-replica-set"}
2022-07-27T10:06:15.900Z DEBUG agent/replica_set_port_manager.go:122 No port change required {"ReplicaSet": "dev/mongodb-replica-set"}
2022-07-27T10:06:15.906Z INFO controllers/replica_set_controller.go:462 Create/Update operation succeeded {"ReplicaSet": "dev/mongodb-replica-set","operation": "updated"}
2022-07-27T10:06:15.906Z INFO controllers/mongodb_tls.go:40 Ensuring TLS is correctly configured {"ReplicaSet": "dev/mongodb-replica-set"}
2022-07-27T10:06:15.906Z WARN controllers/mongodb_tls.go:47 CA resource not found: Secret "tls-ca-key-pair" not found {"ReplicaSet": "dev/mongodb-replica-set"}
[1]. https://github.com/mongodb/mongodb-kubernetes-operator/blob/v0.7.4/docs/install-upgrade.md
[2]. https://github.com/mongodb/mongodb-kubernetes-operator/blob/v0.7.4/docs/deploy-configure.md
[3]. https://github.com/mongodb/mongodb-kubernetes-operator/blob/v0.7.4/docs/secure.md

It had two main reasons.
I followed [1] to enable SSL. It create another Statefulset. After that there are two mongo servers. Uninstall operator and re-install and followed last stable release documentation [2]. After it properly detect configmap and secret.
But it gave SSL issue in certificates as Unsupported Certificate in server modules. Following [3] found the issue. We need to remove extended_key_useage from openssl.conf. Otherwise it not work properly.
Important thread [4]
Hope this help.
[1]. https://github.com/mongodb/mongodb-kubernetes-operator/blob/master/docs/secure.md
[2]. https://github.com/mongodb/mongodb-kubernetes-operator/blob/v0.7.4/docs/secure.md
[3]. https://stackoverflow.com/a/61964464/5607943
[4]. https://groups.google.com/g/mongodb-user/c/EmESxx5KK9Q/m/xH6Ul7fTBQAJ

Related

OpenVPN certificate expired on server

I have a server from my university, I used a vpn to connect to this server. The VPN was located on this server. To connect to this server , I used an OpenVPN .ovpn file with the configuration as follows:
# student.ovpn
client
dev tun
proto tcp
remote my.best.server.ip 443
resolv-retry infinite
nobind
#user nobody
#group nogroup
persist-key
persist-tun
remote-cert-tls server
cipher AES-256-CBC
auth SHA256
key-direction 1
verb 3
auth-user-pass
<key>
-----BEGIN PRIVATE KEY-----
...
-----END PRIVATE KEY-----
</key>
<cert>
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 2 (0x2)
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=RU, ST=Moscow, L=Moscow, O=HSE, OU=HSE, CN=HSE/name=HSE/emailAddress=a#hse.ru
Validity
Not Before: Nov 18 10:00:42 2020 GMT
Not After : Nov 16 10:00:42 2030 GMT
Subject: C=RU, ST=Moscow, L=Moscow, O=HSE, OU=HSE, CN=students/name=HSE/emailAddress=a#hse.ru
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (4096 bit)
Modulus:
...
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
</cert>
<ca>
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
</ca>
<tls-auth>
#
# 2048 bit OpenVPN static key
#
-----BEGIN OpenVPN Static key V1-----
...
-----END OpenVPN Static key V1-----
</tls-auth>
On September 5th, my server's certificate expired and my website is unavailable. To update this certificate, I have to connect to the server. But I can't do it because the server is only accessible via VPN and I can't connect to VPN:
$ openvpn student.ovpn
[entering log/pass]
2022-09-09 02:20:41 Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
2022-09-09 02:20:41 Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
2022-09-09 02:20:41 TCP/UDP: Preserving recently used remote address: [AF_INET]92.242.58.252:443
2022-09-09 02:20:41 Socket Buffers: R=[131072->131072] S=[16384->16384]
2022-09-09 02:20:41 Attempting to establish TCP connection with [AF_INET]92.242.58.252:443 [nonblock]
2022-09-09 02:20:42 TCP connection established with [AF_INET]my.best.server.ip:443
2022-09-09 02:20:42 TCP_CLIENT link local: (not bound)
2022-09-09 02:20:42 TCP_CLIENT link remote: [AF_INET]my.best.server.ip:443
2022-09-09 02:20:42 TLS: Initial packet from [AF_INET]my.best.server.ip:443, sid=ab38e0e0 b8b65c7c
2022-09-09 02:20:42 VERIFY OK: depth=1, C=RU, ST=Moscow, L=Moscow, O=HSE, OU=HSE, CN=HSE, name=HSE, emailAddress=a#hse.ru
2022-09-09 02:20:42 VERIFY KU OK
2022-09-09 02:20:42 Validating certificate extended key usage
2022-09-09 02:20:42 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
2022-09-09 02:20:42 VERIFY EKU OK
2022-09-09 02:20:42 VERIFY OK: depth=0, C=RU, ST=Moscow, L=Moscow, O=HSE, OU=HSE, CN=server, name=HSE, emailAddress=a#hse.ru
2022-09-09 02:20:57 Connection reset, restarting [-1]
2022-09-09 02:20:57 SIGUSR1[soft,connection-reset] received, process restarting
2022-09-09 02:20:57 Restart pause, 5 second(s)
Is there any way I can update my .ovpn file or accept an insecure (expired) certificate to gain access to my server?

How to handle Kafka cluster CA certificate?

I have installed Strimzi Kafka and created TLS enabled cluster as follows:
listeners:
plain: {}
tls:
authentication:
type: tls
The Kafka cluster CA certificate created automatically and looks like this:
Entry type: trustedCertEntry
Owner: CN=cluster-ca v0, O=io.strimzi
Issuer: CN=cluster-ca v0, O=io.strimzi
Serial number: def376173b64bf84
Valid from: Tue Jan 26 23:25:07 MSK 2021 until: Wed Jan 26 23:25:07 MSK 2022
Certificate fingerprints:
SHA1: 4D:AA:27:0F:84:61:88:D0:B8:1C:CB:9A:DD:5F:D3:E8:3D:52:B4:65
The question is: what should I do after a year passed (as the certificate automatically created with 1 year period). I use TLS authentication for the clients (producers/consumers) -- and as a result I add this certificate to SSL truststore on the client side. What should I need on the client after a year passed? I guess update truststore with new cluster CA certificate?
The CA will be automatically renewed by Strimzi. You can just update your truststore and keep using your cluster. If you prefer, you can also provide your own certificate for the listener: https://strimzi.io/docs/operators/latest/full/using.html#kafka-listener-certificates-str or your own CA: https://strimzi.io/docs/operators/latest/full/using.html#installing-your-own-ca-certificates-str

Can't connect to mongodb with self-signed certificate, mongodb in docker container

I have created a docker container with a mongodb image. I created a self-signed certificate for the secure connections to the database following this guide.
I started trying to make a connection with these certificates where rootCA.pem is the self-signed certificate of the computer that will become the certifier, in this case the same. And mongodb.pem is the .key of the server + the .crt.
root#8bc7b8cd6a0d:/# mongo --tls --tlsCAFile /data/db/certs/rootCA.pem --tlsCertificateKeyFile /data/db/certs/mongodb.pem --host 172.17.0.2:27017
MongoDB shell version v4.2.6
connecting to: mongodb://172.17.0.2:27017/?compressors=disabled&gssapiServiceName=mongodb
2020-04-29T09:21:21.255+0000 E QUERY [js] Error: couldn't connect to server 172.17.0.2:27017, connection attempt failed: SocketException: stream truncated :
connect#src/mongo/shell/mongo.js:341:17
#(connect):2:6
2020-04-29T09:21:21.259+0000 F - [main] exception: connect failed
2020-04-29T09:21:21.259+0000 E - [main] exiting with code 1
root#8bc7b8cd6a0d:/#
root#8bc7b8cd6a0d:/# mongo --tls --tlsCAFile /data/db/certs/rootCA.pem --tlsCertificateKeyFile /data/db/certs/mongodb.pem
MongoDB shell version v4.2.6
connecting to: mongodb://127.0.0.1:27017/?compressors=disabled&gssapiServiceName=mongodb
2020-05-05T19:39:52.308+0000 E QUERY [js] Error: couldn't connect to server 127.0.0.1:27017, connection attempt failed: SocketException: stream truncated :
connect#src/mongo/shell/mongo.js:341:17
#(connect):2:6
2020-05-05T19:39:52.358+0000 F - [main] exception: connect failed
2020-05-05T19:39:52.359+0000 E - [main] exiting with code 1
root#8bc7b8cd6a0d:/#
The certificates are stored in the following directory, which is in a volume to the container to store the data from the database.
root#auzal-virtual-machine:/opt/mimongo# ls certs
mongodb.crt mongodb.csr mongodb.key mongodb.pem rootCA.key rootCA.pem rootCA.srl
Finally the configuration file is structured in the following way, this file is a copy of the original, I say this in case you see that the name is different from normal:
# for documentation of all options, see:
# http://docs.mongodb.org/manual/reference/configuration-options/
# Where and how to store data.
storage:
dbPath: /var/lib/mongodb
journal:
enabled: true
# engine:
# mmapv1:
# wiredTiger:
# where to write logging data.
systemLog:
destination: file
logAppend: true
path: /var/log/mongodb/mongod.log
# network interfaces
net:
port: 27017
bindIp: 127.0.0.1
ssl:
mode: requireSSL
PEMKeyFile: /data/db/certs/mongodb.pem
CAFile: /data/db/certs/rootCA.pem
# how the process runs
processManagement:
timeZoneInfo: /usr/share/zoneinfo
#security:
#operationProfiling:
#replication:
#sharding:
## Enterprise-Only Options:
#auditLog:
#snmp:
I don't know why I get that error, could it be that I am interpreting something wrong with the certificates and not indicating the correct one? What is the error I receive?
reviewing the logs with a statement within the database I get the following error, however this ability in the main configuration file:
Error receiving request from client: SSLHandshakeFailed: SSL handshake received but server is started without SSL support.
The authentication you see is from an administrator user but without a certificate
"2020-05-06T21:46:58.796+0000 I NETWORK [conn3] end connection 127.0.0.1:56360 (0 connections now open)",
"2020-05-06T21:47:02.052+0000 I NETWORK [listener] connection accepted from 127.0.0.1:56362 #4 (1 connection now open)",
"2020-05-06T21:47:02.053+0000 I NETWORK [conn4] Error receiving request from client: SSLHandshakeFailed: SSL handshake received but server is started without SSL support. Ending connection from 127.0.0.1:56362 (connection id: 4)",
"2020-05-06T21:47:02.053+0000 I NETWORK [conn4] end connection 127.0.0.1:56362 (0 connections now open)",
"2020-05-06T21:47:08.628+0000 I NETWORK [listener] connection accepted from 127.0.0.1:56364 #5 (1 connection now open)",
"2020-05-06T21:47:08.629+0000 I NETWORK [conn5] Error receiving request from client: SSLHandshakeFailed: SSL handshake received but server is started without SSL support. Ending connection from 127.0.0.1:56364 (connection id: 5)",
"2020-05-06T21:47:08.629+0000 I NETWORK [conn5] end connection 127.0.0.1:56364 (0 connections now open)",
"2020-05-06T21:47:11.815+0000 I NETWORK [listener] connection accepted from 127.0.0.1:56366 #6 (1 connection now open)",
"2020-05-06T21:47:11.816+0000 I NETWORK [conn6] Error receiving request from client: SSLHandshakeFailed: SSL handshake received but server is started without SSL support. Ending connection from 127.0.0.1:56366 (connection id: 6)",
"2020-05-06T21:47:11.817+0000 I NETWORK [conn6] end connection 127.0.0.1:56366 (0 connections now open)",
"2020-05-06T21:47:21.515+0000 I NETWORK [listener] connection accepted from 127.0.0.1:56368 #7 (1 connection now open)",
"2020-05-06T21:47:21.515+0000 I NETWORK [conn7] Error receiving request from client: SSLHandshakeFailed: SSL handshake received but server is started without SSL support. Ending connection from 127.0.0.1:56368 (connection id: 7)",
"2020-05-06T21:47:21.516+0000 I NETWORK [conn7] end connection 127.0.0.1:56368 (0 connections now open)",
"2020-05-06T21:50:17.250+0000 I NETWORK [listener] connection accepted from 127.0.0.1:56374 #8 (1 connection now open)",
"2020-05-06T21:50:17.251+0000 I NETWORK [conn8] Error receiving request from client: SSLHandshakeFailed: SSL handshake received but server is started without SSL support. Ending connection from 127.0.0.1:56374 (connection id: 8)",
"2020-05-06T21:50:17.251+0000 I NETWORK [conn8] end connection 127.0.0.1:56374 (0 connections now open)",
"2020-05-06T21:51:48.008+0000 I NETWORK [listener] connection accepted from 127.0.0.1:56396 #9 (1 connection now open)",
"2020-05-06T21:51:48.009+0000 I NETWORK [conn9] received client metadata from 127.0.0.1:56396 conn9: { application: { name: \"MongoDB Shell\" }, driver: { name: \"MongoDB Internal Client\", version: \"4.2.6\" }, os: { type: \"Linux\", name: \"Ubuntu\", architecture: \"x86_64\", version: \"18.04\" } }",
"2020-05-06T21:51:54.405+0000 I NETWORK [conn9] end connection 127.0.0.1:56396 (0 connections now open)",
"2020-05-06T21:52:03.681+0000 I NETWORK [listener] connection accepted from 127.0.0.1:56402 #10 (1 connection now open)",
"2020-05-06T21:52:03.682+0000 I NETWORK [conn10] received client metadata from 127.0.0.1:56402 conn10: { application: { name: \"MongoDB Shell\" }, driver: { name: \"MongoDB Internal Client\", version: \"4.2.6\" }, os: { type: \"Linux\", name: \"Ubuntu\", architecture: \"x86_64\", version: \"18.04\" } }",
"2020-05-06T21:52:03.682+0000 I SHARDING [conn10] Marking collection admin.system.users as collection version: <unsharded>",
"2020-05-06T21:52:03.776+0000 I ACCESS [conn10] SASL SCRAM-SHA-256 authentication failed for admin on admin from client 127.0.0.1:56402 ; AuthenticationFailed: SCRAM authentication failed, storedKey mismatch",
"2020-05-06T21:52:03.786+0000 I NETWORK [conn10] end connection 127.0.0.1:56402 (0 connections now open)",
"2020-05-06T21:52:16.138+0000 I NETWORK [listener] connection accepted from 127.0.0.1:56404 #11 (1 connection now open)",
"2020-05-06T21:52:16.139+0000 I NETWORK [conn11] received client metadata from 127.0.0.1:56404 conn11: { application: { name: \"MongoDB Shell\" }, driver: { name: \"MongoDB Internal Client\", version: \"4.2.6\" }, os: { type: \"Linux\", name: \"Ubuntu\", architecture: \"x86_64\", version: \"18.04\" } }",
"2020-05-06T21:52:16.215+0000 I ACCESS [conn11] Successfully authenticated as principal admin on admin from client 127.0.0.1:56404"
],
"ok" : 1
}
> db.adminCommand( { getLog: "global" } )
I followed this guide when creating my certificate. I initially used the certificate created from here but it didn't work. Using the server certificate did the trick.

MongoDB Shell connection errors using test self signed certificates

I am trying to test a mongoDB installation with self signed certificates. I followed the instructions in the mongoDB documentation for creating the 'pem' files using the copy links on each page:
Appendix A - OpenSSL CA Certificate for Testing
Appendix B - OpenSSL Server Certificates for Testing
Appendix C - OpenSSL Client Certificates for Testing
I updated the /etc/mongod.conf as such:
# network interfaces
net:
port: 27017
bindIp: 0.0.0.0
tls:
mode: requireTLS
certificateKeyFile: /etc/ssl/mongodb/test-server1.pem
allowConnectionsWithoutCertificates: true
allowInvalidHostnames: true
allowInvalidCertificates: true
CAFile: /etc/ssl/mongodb/mongodb-test-ca.crt
Originally I did not have the 'allow' option, but they do not make a difference so I am leaving the in for now.
Running the mongodb shell results in this error:
root#ip-10-0-3-61:~/mongo-cert# mongo --tls --tlsCertificateKeyFile test-client.pem
MongoDB shell version v4.2.5
connecting to: mongodb://127.0.0.1:27017/?compressors=disabled&gssapiServiceName=mongodb
2020-04-17T17:07:25.809+0000 E NETWORK [js] SSL peer certificate validation failed: self signed certificate in certificate chain
2020-04-17T17:07:25.810+0000 E QUERY [js] Error: couldn't connect to server 127.0.0.1:27017, connection attempt failed: SSLHandshakeFailed: SSL peer certificate validation failed: self signed certificate in certificate chain :
connect#src/mongo/shell/mongo.js:341:17
#(connect):2:6
2020-04-17T17:07:25.812+0000 F - [main] exception: connect failed
2020-04-17T17:07:25.812+0000 E - [main] exiting with code 1
root#ip-10-0-3-61:~/mongo-cert#
If I add the '--tlsAllowInvalidCertificates' in the command it works:
root#ip-10-0-3-61:~/mongo-cert# mongo --tls --tlsCertificateKeyFile test-client.pem --tlsAllowInvalidCertificates
MongoDB shell version v4.2.5
connecting to: mongodb://127.0.0.1:27017/?compressors=disabled&gssapiServiceName=mongodb
2020-04-17T17:09:18.934+0000 W NETWORK [js] SSL peer certificate validation failed: self signed certificate in certificate chain
Implicit session: session { "id" : UUID("3b0d0920-931d-4143-a8a2-afde432c1444") }
MongoDB server version: 4.2.5
>
I have read other people who have followed the mongodb instructions successfully.
I just do not understand what I have done wrong.
You need to provide the CA file to mongo also (the --tlsCAFile option), in addition to the client certificate.
When full verification is enabled with TLS both server and client validate the other's certificate. This means both must have access to the CA cert used for signing the leaf certs.

IO::Socket::SSL client checking server certificate

I want to use server certificate when connecting with IO::Socket::SSL client.
What I did is to extract certificate first,
openssl s_client -showcerts -connect 127.0.0.1:443 </dev/null 2>/dev/null|openssl x509 -outform PEM >/tmp/localhost.crt
-----BEGIN CERTIFICATE-----
MIID1jCCAr6gAwIBAgICBH8wDQYJKoZIhvcNAQELBQAwgZ8xCzAJBgNVBAYTAi0t
MRIwEAYDVQQIDAlTb21lU3RhdGUxETAPBgNVBAcMCFNvbWVDaXR5MRkwFwYDVQQK
DBBTb21lT3JnYW5pemF0aW9uMR8wHQYDVQQLDBZTb21lT3JnYW5pemF0aW9uYWxV
bml0MRAwDgYDVQQDDAdiaWdnZXIyMRswGQYJKoZIhvcNAQkBFgxyb290QGJpZ2dl
cjIwHhcNMTYwODA0MDUyMTA5WhcNMTcwODA0MDUyMTA5WjCBnzELMAkGA1UEBhMC
LS0xEjAQBgNVBAgMCVNvbWVTdGF0ZTERMA8GA1UEBwwIU29tZUNpdHkxGTAXBgNV
BAoMEFNvbWVPcmdhbml6YXRpb24xHzAdBgNVBAsMFlNvbWVPcmdhbml6YXRpb25h
bFVuaXQxEDAOBgNVBAMMB2JpZ2dlcjIxGzAZBgkqhkiG9w0BCQEWDHJvb3RAYmln
Z2VyMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALSJplghG5oD5FhU
1v9IkE8z0k/7g1W29GhUXwf7IKzzjplIgpsZ+Ya/OtDbIctSYZ3gNEMyj+LdlvEW
6rCDCSTULPWwdjuSdHmUiFyeJm+QBtnMIp9I3P7zPCd+W9Cyhue911tXCHiQMg+E
ZNi2WlqnBGf/5l6VFRVMxQTEbTRiTPaH9VFnuyCKcJTk9ephZmZRgfeNmXT7BRjG
nmsYa0jG2rh2UmJGQrJhZOZYmghbq1BL66m7yCxfknsjTHGfy7PS/c+K83fPVI0p
bcBgl0VCA7d8TX6xj4BwMec7nwdi95ISVAG3jjL11+lrlcg6UGs+bd+NVpd1PbVY
XwVcWu8CAwEAAaMaMBgwCQYDVR0TBAIwADALBgNVHQ8EBAMCBeAwDQYJKoZIhvcN
AQELBQADggEBAFkWi/C8UlEqXPO0aDrn78teYzh3D0BIuhB4vawDSUuz68Clq41u
bMLIbdWZS244NFLeWAYJf4k0WDk7/nz5pxWLqlDg4LumZxNOUeSWUSbantRn6NnQ
rJrWZi6gJFgeC/34t3k+XvtmbDl5a2L213TxOtnSZJty/ZxUr3v3Z3Dp5+kfTAyR
xlD/gOlAEHgrOjwv1XofVb5pALPjzGj9gAfe/bpMEG4GORgtJzFz/teugL4yZ4Mk
sk6BhIBd1hTWJXUfvH6GPaoieug46CAkolmvc0q2nfMiU+hZOkDE1rtyqS5XMF5t
O2nma+wuMF6z/naEXFPq65sFOHI8vz+oEaQ=
-----END CERTIFICATE-----
and then connect using ssl_client.pl from examples folder,
ssl_client.pl -d10 --ca /tmp/localhost.crt localhost:443
DEBUG: .../IO/Socket/SSL.pm:2757: new ctx 17132992
DEBUG: .../IO/Socket/SSL.pm:643: socket not yet connected
DEBUG: .../IO/Socket/SSL.pm:645: socket connected
DEBUG: .../IO/Socket/SSL.pm:667: ssl handshake not started
DEBUG: .../IO/Socket/SSL.pm:700: using SNI with hostname localhost
DEBUG: .../IO/Socket/SSL.pm:735: request OCSP stapling
DEBUG: .../IO/Socket/SSL.pm:769: call Net::SSLeay::connect
DEBUG: .../IO/Socket/SSL.pm:2658: did not get stapled OCSP response
DEBUG: .../IO/Socket/SSL.pm:2611: ok=0 [0] /C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=bigger2/emailAddress=root#bigger2/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=bigger2/emailAddress=root#bigger2
DEBUG: .../IO/Socket/SSL.pm:772: done Net::SSLeay::connect -> -1
DEBUG: .../IO/Socket/SSL.pm:775: SSL connect attempt failed
DEBUG: .../IO/Socket/SSL.pm:775: local error: SSL connect attempt failed error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
DEBUG: .../IO/Socket/SSL.pm:778: fatal SSL error: SSL connect attempt failed error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
DEBUG: ...inux/IO/Socket.pm:49: ignoring less severe local error 'IO::Socket::INET configuration failed', keep 'SSL connect attempt failed error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed'
DEBUG: .../IO/Socket/SSL.pm:2779: free ctx 17132992 open=17132992
DEBUG: .../IO/Socket/SSL.pm:2784: free ctx 17132992 callback
DEBUG: .../IO/Socket/SSL.pm:2791: OK free ctx 17132992
failed to connect to localhost:443: ,SSL connect attempt failed error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed at ./ssl_client.pl line 52.
This doesn't work as expected, so please suggest how to properly verify server using locally stored certificate.
While your certificate is self-signed (i.e. signed by itself) it is not a CA:
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Because it is not a CA it is not allowed to be used as an issuer of a certificate and thus can in theory not even be used to sign itself.
This is at least the logic implemented in OpenSSL (and thus Net::SSLeay, IO::Socket::SSL). Other implementations like NSS seem to work with such certificates probably because they check if the server certificate itself is explicitly trusted. Such a check is different from only checking if it is signed by a trusted CA which is done by using the SSL_ca* options in IO::Socket::SSL (or -CAfile, -CApath arguments in openssl s_client).
Explicitly trusting a specific certificate no matter if it is self-signed, expired, revoked or whatever can be done in IO::Socket::SSL by using the SSL_fingerprint option.
Note that debugging IO::Socket::SSL in this case does not help a lot since the logic in this case is implemented in OpenSSL. There is some small indicator where it is going wrong:
DEBUG: ... ok=0 [0] .../CN=bigger2/emailAddress=root#bigger2 .../CN=bigger2/emailAddress=root#bigger2
This debug statement is called from the verification callback. ok=0 [0] indicates that this callback was called with ok=0 at level certificate level 0, i.e. that the built-in validation of OpenSSL did not consider this certificate as valid.