How would you feel about a feature request to allow this particular bit of "oh fine, whattever" configuration in mosquitto bridges?
Motivation / a rant
(note this is somewhat irrelevant to mosquitto, I'm just shouting into the void because I am irritated with technology)
If you are wondering why exactly I'd want this, it's because I'd like to setup a bridge for the MQTT broker running on an irobot roomba. The roomba's MQTT server only supports ssl connections. However there is some issue with the certificate chain being used:
> openssl s_client -connect 192.168.2.5:8883 -CAfile irobot0.pem -showcerts < /dev/null
CONNECTED(00000003)
Can't use SSL_get_servername
depth=1 C = US, ST = Massachusetts, L = Beford, O = iRobot Corporation, OU = HBU, CN = Robot Intermediate CA A01
verify error:num=26:unsupported certificate purpose
verify return:1
depth=2 C = US, ST = MA, L = Bedford, O = iRobot, OU = HBU, CN = Roomba CA
verify return:1
depth=1 C = US, ST = Massachusetts, L = Beford, O = iRobot Corporation, OU = HBU, CN = Robot Intermediate CA A01
verify return:1
depth=0 C = US, ST = Massachusetts, L = Bedford, O = iRobot Corporation, OU = Production, CN = iRobot-783545A45675422DB5A4576E7829A1F4
verify return:1
---
Certificate chain
0 s:C = US, ST = Massachusetts, L = Bedford, O = iRobot Corporation, OU = Production, CN = iRobot-783545A45675422DB5A4576E7829A1F4
i:C = US, ST = Massachusetts, L = Beford, O = iRobot Corporation, OU = HBU, CN = Robot Intermediate CA A01
-----BEGIN CERTIFICATE-----
[elided...]
-----END CERTIFICATE-----
1 s:C = US, ST = Massachusetts, L = Beford, O = iRobot Corporation, OU = HBU, CN = Robot Intermediate CA A01
i:C = US, ST = MA, L = Bedford, O = iRobot, OU = HBU, CN = Roomba CA
-----BEGIN CERTIFICATE-----
[elided...]
-----END CERTIFICATE-----
---
Server certificate
subject=C = US, ST = Massachusetts, L = Bedford, O = iRobot Corporation, OU = Production, CN = iRobot-783545A45675422DB5A4576E7829A1F4
issuer=C = US, ST = Massachusetts, L = Beford, O = iRobot Corporation, OU = HBU, CN = Robot Intermediate CA A01
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 3140 bytes and written 409 bytes
Verification error: unsupported certificate purpose
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID: ECC2C6292FEF8460D9163B26BA0690ADED545EF5413E90B34642AAA7C2948C38
Session-ID-ctx:
Master-Key: EB6F31AB4C4244C4D55A7EB837B47DA6DED757C6C2495147DD0BEE1A4D8995553841CB052530F6A93894ADA361542FAA
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
[elided...]
Start Time: 1612116240
Timeout : 7200 (sec)
Verify return code: 26 (unsupported certificate purpose)
Extended master secret: no
---
DONE
You'll notice verification failed with verify error:num=26:unsupported certificate purpose on the intermediate cert. Closer inspection of the intermediate cert:
openssl x509 --noout -in roomba_intermediate.pem -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
7f:ff:ad:ad:33:1e:00:38:32:4c:a1:5d:3b:9a:0b:27:38:1c
Signature Algorithm: sha256WithRSAEncryption
Issuer: C = US, ST = MA, L = Bedford, O = iRobot, OU = HBU, CN = Roomba CA
Validity
Not Before: May 7 18:11:42 2018 GMT
Not After : Dec 31 00:00:00 2025 GMT
Subject: C = US, ST = Massachusetts, L = Beford, O = iRobot Corporation, OU = HBU, CN = Robot Intermediate CA A01
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public-Key: (4096 bit)
Modulus:
[elided...]
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Key Usage: critical
Certificate Sign
X509v3 Basic Constraints: critical
CA:TRUE, pathlen:0
X509v3 Extended Key Usage:
Any Extended Key Usage, 1.3.6.1.4.1.50748.2.2.8
Signature Algorithm: sha256WithRSAEncryption
[elided...]
Applications that require the presence of a
particular purpose MAY reject certificates that include the
anyExtendedKeyUsage OID but not the particular OID expected for the
application. If a certificate contains both a key usage extension and an extended
key usage extension, then both extensions MUST be processed
independently and the certificate MUST only be used for a purpose
consistent with both extensions. If there is no purpose consistent
with both extensions, then the certificate MUST NOT be used for any
purpose.
I believe that openssl might be being very strict, as it has come up with this list as the set of valid purposes for the cert:
> openssl x509 --noout -in roomba_intermediate.pem -purpose
Certificate purposes:
SSL client : No
SSL client CA : No
SSL server : No
SSL server CA : No
Netscape SSL server : No
Netscape SSL server CA : No
S/MIME signing : No
S/MIME signing CA : No
S/MIME encryption : No
S/MIME encryption CA : No
CRL signing : No
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
I think SSL server CA : No is most relevant :).
tl;dr is I have a thing that is misconfigured but that I dont control, would love to be able to configure Mosquitto to handle it anyway!
Hi!
It appears that the library allows users to set SSL_VERIFY_NONE as an option when connecting. However, as far as I can tell it is not possible to configure a bridge with this option, as the value is hardcoded.
How would you feel about a feature request to allow this particular bit of "oh fine, whattever" configuration in mosquitto bridges?
Motivation / a rant
(note this is somewhat irrelevant to mosquitto, I'm just shouting into the void because I am irritated with technology)
If you are wondering why exactly I'd want this, it's because I'd like to setup a bridge for the MQTT broker running on an irobot roomba. The roomba's MQTT server only supports ssl connections. However there is some issue with the certificate chain being used:
You'll notice verification failed with
verify error:num=26:unsupported certificate purpose
on the intermediate cert. Closer inspection of the intermediate cert:Notice that both "Key Usage" and "Extended Key Usage" are set. In the X509 RFC Extended Key Usage section there is this:
I believe that openssl might be being very strict, as it has come up with this list as the set of valid purposes for the cert:
I think
SSL server CA : No
is most relevant :).tl;dr is I have a thing that is misconfigured but that I dont control, would love to be able to configure Mosquitto to handle it anyway!