[MXS-3093] Client side certificates for secure REST API fails Created: 2020-07-24  Updated: 2020-12-08  Resolved: 2020-08-24

Status: Closed
Project: MariaDB MaxScale
Component/s: REST-API
Affects Version/s: 2.5.1
Fix Version/s: 2.5.3

Type: Bug Priority: Critical
Reporter: Anders Karlsson Assignee: markus makela
Resolution: Fixed Votes: 0
Labels: None
Environment:

Linux CentOS 7.7

Sprint: MXS-SPRINT-113

 Description   

WIth MariaDB MaxScale configured for TLS for REST like this:

[maxscale]
 
admin_ssl_key=/usr/local/certs/server-key.pem
 
admin_ssl_cert=/usr/local/certs/server-cert.pem
 
admin_ssl_ca_cert=/usr/local/certs/ca-cert.pem

Then you get odd errors when trying to connect using client keys:

$ maxctrl --secure --tls-key=/home/anders/src/blogs/maxscalessl/client-key.pem --tls-cert=/home/anders/src/blogs/maxscalessl/client-cert.pem --tls-ca-cert=/home/anders/src/blogs/maxscalessl/ca-cert.pem list servers
 
TypeError: Converting circular structure to JSON
 
    at JSON.stringify (<anonymous>)
 
    at /snapshot/maxctrl/lib/common.js:0:0
 
    at process._tickCallback (internal/process/next_tick.js:68:7)

Using --tls-verify-server-cert=false makes this work though. And then only the ca-cert is necessary:

$ maxctrl --secure  --tls-ca-cert=/home/anders/src/blogs/maxscalessl/ca-cert.pem list servers --tls-verify-server-cert=false
 
┌─────────┬──────────────┬───────┬─────────────┬───────────────────────────────────────────┬────────────┐
 
│ Server  │ Address      │ Port  │ Connections │ State                                     │ GTID       │
 
├─────────┼──────────────┼───────┼─────────────┼───────────────────────────────────────────┼────────────┤
 
│ server1 │ 192.168.0.11 │ 3306  │ 0           │ Master, Slave of External Server, Running │ 0-1-837377 │
 
├─────────┼──────────────┼───────┼─────────────┼───────────────────────────────────────────┼────────────┤
 
│ server2 │ 192.168.0.11 │ 10503 │ 0           │ Down                                      │            │
 
└─────────┴──────────────┴───────┴─────────────┴───────────────────────────────────────────┴────────────┘

Including only the client certificate cause yet another strange error message:

$ maxctrl --secure --tls-cert=/home/anders/src/blogs/maxscalessl/client-cert.pem --tls-ca-cert=/home/anders/src/blogs/maxscalessl/ca-cert.pem list servers
 
(node:5318) UnhandledPromiseRejectionWarning: TypeError: Cannot read property 'toString' of undefined
 
    at Request.getNewAgent (/snapshot/maxctrl/node_modules/request/request.js:656:63)
 
    at Request.init (/snapshot/maxctrl/node_modules/request/request.js:490:37)
 
    at Request.RP$initInterceptor [as init] (/snapshot/maxctrl/node_modules/request-promise-core/configure/request2.js:45:29)
 
    at new Request (/snapshot/maxctrl/node_modules/request/request.js:127:8)
 
    at request (/snapshot/maxctrl/node_modules/request/index.js:53:10)
 
    at module.exports.simpleRequest (/snapshot/maxctrl/lib/common.js:0:0)
 
    at module.exports.doAsyncRequest (/snapshot/maxctrl/lib/common.js:0:0)
 
    at module.exports.getJson (/snapshot/maxctrl/lib/common.js:0:0)
 
    at /snapshot/maxctrl/lib/list.js:0:0
 
    at /snapshot/maxctrl/lib/common.js:0:0
 
(node:5318) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)
 
(node:5318) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.



 Comments   
Comment by markus makela [ 2020-08-19 ]

The latter error is a bug in MaxCtrl where it doesn't check that both tls-key and tls-cert are defined which I managed to reproduce and fix. The other problems look like some error reporting problems but I haven't been able to reproduce the problem. Can you provide steps on how to create the certificates you used to test this?

This is how I generated the certificates that I used to test:

cat > openssl.cnf <<EOF
 
[ ca ]
 
default_ca      = CA_default           # The default ca section
 
 
 
[ CA_default ]
 
 
 
dir            = ./                    # top dir
 
database       = ./index.txt           # index file.
 
new_certs_dir  = ./newcerts            # new certs dir
 
 
 
certificate    = ./ca-cert.pem         # The CA cert
 
serial         = ./serial.txt          # serial no file
 
rand_serial    = yes                   # for random serial#'s
 
private_key    = ./ca-key.pem          # CA private key
 
 
 
default_days   = 2048                  # how long to certify for
 
default_crl_days= 30                   # how long before next CRL
 
default_md     = sha1                  # md to use
 
 
 
policy         = policy_any            # default policy
 
email_in_dn    = no                    # Don't add the email into cert DN
 
 
 
name_opt       = ca_default            # Subject name display option
 
cert_opt       = ca_default            # Certificate display option
 
copy_extensions = none                 # Don't copy extensions from request
 
 
 
[ policy_any ]
 
countryName            = supplied
 
stateOrProvinceName    = optional
 
organizationName       = optional
 
organizationalUnitName = optional
 
commonName             = supplied
 
emailAddress           = optional
 
EOF
 
 
 
mkdir newcerts
 
touch index.txt
 
echo '01' > serial.txt
 
 
 
openssl req -x509 -nodes -newkey rsa:4096 -keyout ca-key.pem -out ca-cert.pem -days 2048 -subj '/CN=localhost/O=Certificate Authority/countryName=FI/'
 
 
 
openssl req -nodes -newkey rsa:4096 -keyout server-key.pem -out server.csr -subj '/CN=localhost/O=Server/countryName=FI/'
 
openssl ca -batch -config openssl.cnf -in server.csr -out server-cert.pem
 
 
 
openssl req -nodes -newkey rsa:4096 -keyout client-key.pem -out client.csr -subj '/CN=localhost/O=Client/countryName=FI/'
 
openssl ca -batch -config openssl.cnf -in client.csr -out client-cert.pem

Comment by markus makela [ 2020-08-24 ]

Closing as fixed until we get a reproducible test case.

Generated at Thu Feb 08 04:18:54 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.