REST API/SSL & python

RouterOS Scripting
1

Had some fun getting SSL to work with python requests & a mikrotik auto-generated let’s encrypt certificate.

The cert generation went fine, but initially trying to access in python3 requests would fail with

ssl.SSLCertVerificationError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1131)

even though it works in chrome w/o issue.

This is because mikrotik does not serve the full SSL chain, even if it is imported on router, and it seems linux often does not have the intermediate certs for LE loaded.

But manually creating a chain works

$ wget https://letsencrypt.org/certs/isrgrootx1.pem
$ wget https://letsencrypt.org/certs/lets-encrypt-r3.pem
$ cat isrgrootx1.pem >> certstore.pem
$ cat lets-encrypt-r3.pem >> certstore.pem

and then certstore.pem can be used in python like

import requests
r = requests.get('https://mikrotik.example.com/rest/system/resource', auth=('user', 'pass'), verify="/path/to/certstore.pem")

Apparently browsers sometimes cache intermediate certificates? Or are smarter about fetching them? and normally webservers give out full chains? Would be nice if RouterOS would give full chain if one is available, since these certs are normally trusted. I can see the point of not giving the chain for an internal only-cert, but for a commonly trusted CA I was hoping to not need to carry special .pem files around with scripts anymore.

2

A device that does verification should have a full chain imported. Chrome has its own certificate manager, where it has all the ca and intermediate certificates.

3

It seems like it is not uncommon for a server to offer a full certificate chain to a client, and for most OS to only hold root certs. This is somewhat expected when using a commonly trusted root CA.

Eg, other bug mentioning requests lib claims most OS do not include intermediate certs and servers should serve them.
https://github.com/psf/requests/issues/2955#issuecomment-222098821

Apache used to have configuration SSLCertificateChainFile to load and serve intermediate certs, but now is integrated and loading of full chain happens by default. I think it is normal to expect a web server to offer full chain.

This kind of explains my position better: https://serverfault.com/a/382638.

When tracing trust to a commonly accepted root cert, it is nice for the server to explain fully why it is trusted. My client only needs to hold a small number of root certs then. Intermediate certs might be short lived & not get updated on my IOT device. Let’s Encrypt has already deprecated 4 intermediate certs.

4

RouterOS currently does not have functionality to offer the whole chain.

5

I don’t think that’s true. My RouterOS happily serves intermediate certificates, if they are present. The problem with LE client in RouterOS is that it doesn’t add any.

6

Oh wow, you’re right. I messed up importing the R3 cert and only had X1 imported. /facepalm

After importing R3 it works for me too now, without specifying a custom pem chain. Openssl cli is happy:

$ openssl s_client -connect <redacted host>:443 
CONNECTED(00000003)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = <redacted host>
verify return:1
---
Certificate chain
 0 s:CN = <redacted host>
   i:C = US, O = Let's Encrypt, CN = R3
 1 s:C = US, O = Let's Encrypt, CN = R3
   i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
 2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1
   i:C = US, O = Internet Security Research Group, CN = ISRG Root X1