DoH server connection error: SSL: ssl: crl not found for: “C=US, S=California, L=San Francisco, O=Cloudflare, Inc., CN=cloudflare-dns.com” (6)
How to fix this? I already removed all the certificates and re-installed. But still same.
REF: https://help.mikrotik.com/docs/pages/viewpage.action?pageId=83099652
From 7.19 on you no longer need to install external CA root certificate to use DoH from Cloudflare. You can use the built-in CA shipped with RouterOS. You need to turn this setting on:
/certificate/settings/set builtin-trust-anchors=trusted
Also, because you need DoH to resolve domains, you should not enable CRL Download or Use CRL. These settings are off by default. You can turn them off with
/certificate/settings/set crl-use=no crl-download=no
Thank you — I had the same issue, and your solution helped! Could you please explain why we should not use the CRL? Why doesn’t it work with the CRL enabled? Wouldn’t it be more secure to use the CRL?
Because to download the CRL the router needs to access an URL, the URL normally uses a domain name (not an IP address), but to resolve that domain name, the router needs to ask the DNS resolver, and DoH is configured, so HTTPS is needed, a certificate needs to be validated, and we are back to the step where the CRL needs to be downloaded 
That’s why turning on CRL verification might cause DoH to fail.
If you know the exact URL used by the CRL of the CA of the certificate that your DoH provider uses, maybe you can add a static DNS entry for that domain (domain of the CA’s CRL’s URL), and would be able to turn on crl-use=yes and crl-download=yes. But you would need to monitor that certificate for any CRL URL changes in the future.
Thank you CGGXANNX. I had the same issue as well. This resolved it.
Quick question, will disabling crl affect any other certs that use crl? Like let’s encrypt for mikrotik ddns? That cert downloads every hour. Not sure if it needs an hourly update since it’s valid for 90 days. I’d assume it’ll be fine
That makes sense — thank you for the clarification, CGGXANNX! Nevertheless, it would be nice if it could be solved somehow. Perhaps it could use DoH without CRL to download the list initially, and then use the CRL afterwards? I’m sure the developers can come up with a great solution.
I didn’t want to disable CRL checking or downloading, so I just looked at the CDP on the cert for Cloudflare’s DoH, and manually configured them. It worked great!
http://crl3.digicert.com/DigiCertGlobalG2TLSRSASHA2562020CA1-1.crl
http://crl4.digicert.com/DigiCertGlobalG2TLSRSASHA2562020CA1-1.crl
Could you explain what you did?
I was asking you how you configured the certificates, although I've already solved the main problem. I deleted all the certificates that appear on the NextDNS configuration page, since Mikrotik already includes the certificates and it worked for me without disabling anything.
That's all it takes, and it works flawlessly.
/ip dns set servers=""
/ip dns static add name=dns.nextdns.io address=45.90.28.0 type=A
/ip dns static add name=dns.nextdns.io address=45.90.30.0 type=A
/ip dns static add name=dns.nextdns.io address=2a07:a8c0:: type=AAAA
/ip dns static add name=dns.nextdns.io address=2a07:a8c1:: type=AAAA
/ip dns set use-doh-server=“https://dns.nextdns.io/123456” verify-doh-cert=yes
Aloha Santi70,
Yes, I’ve used a very similar configuration, albeit pointed to Cloudflare, for years. It does indeed work great. I’m glad you so quickly found a solution.
Unless I’m misunderstanding, I believe this thread is primarily about solving the chicken-and-the-egg problem CRL-USE=YES causes. If in order to get DNS going you need to check your DOH certificate against the CRL, and the CRL location is a URL(not IP), how will you resolve the domain name to download the CRL to verify the DOH cert so you can send the DNS query in the first place? I know other solutions(example: AdGuard) has the concept of bootstrap DNS servers(unsecure, not DOH) which are used to resolve the CRL URL when checking the DOH’s cert, or resolving the DOH’s domain name, for that matter.
My solution is about pre-loading the CRL to begin with and saving it to the system. I have to download the DOH’s CA cert anyway to trust it. I simply take the next step of inspecting the CA cert to determine the CRL URL, down the CRL(it’s just a text file hosted via HTTP), and load it manually into my Mikrotik. Then, Mikrotik’s CRL features will automatically download fresh copies of the CRL to update the one I have so I always have the latest copy saved to non-volatile memory. In that way, I’m able to bootstrap the CRL check process, trust the DOH cert, get DNS up, then keep my CRL updated.
I know Mikrotik are always releasing patches and updates, so I wouldn’t be surprised if they come out with a knob you can flip to do unsecure DNS queries just to download the CRL and bootstrap the DOH.
But, all this is not applicable, if CRL-USE=NO, which is the default.
Ha! I’m glad you engaged me Santi70, because it caused me to review some patch. Apparently, Mikrotik has been doing some updates with their DNS server over the last year or so. For instance, static FWD entries used to not work with DOH configured, but now they do. That’s awesome, because you can use those to create blacklist exemptions(a.k.a. whitelist entries). Furthermore, the FWD feature can now be used to bootstrap the CRL. For instance, Cloudflare’s DOH cert is signed by DigiCert, and the CRL resides at crl3.digicert.com and crl4.digicert.com. I can create static FWD entries for those URLs to FORWARD-TO=1.1.1.1 without DOH, and now the CRLs can be downloaded before DOH is up, to then bring DOH up. Su-weet!
After a few years using the DoH client implementation on MikroTik's routers, I think that the experience in recent RouterOS versions has become quite sluggish, sometimes there can be pauses of over 1 second, very frequent when visiting web pages after a while. I was using Cloudflare as DoH provider, but it was the same with Google.
I've recently switched to using unbound in a container runing on the routers, with DoT upstream, also to Cloudflare (unbound doesn't support DoH upstream). And the huge performance improvement is very noticeable! That can easily be seen on test pages like dnscheck.tools, that fire up hundreds of DNS queries. The initial paint when visiting web sites is much quicker.
I just keep the DHCP server / IPv6 RA settings telling the VLANs that the router's IP addresses are the DNS servers, but then use DSTNAT rules (3×IPv4 and 3×IPv6 for 53 TCP, 53 UDP and 853 TCP) to redirect to the container's IPs. unbound still uses the router as upstream for the lan. as well as in-addr.arpa. and ip6.arpa. domains, so that the router can still manage my local static DNS records (that are populated/modified by scripts).
Also, adding a certificate issued by Let's Encrypt and DoT works in LAN too. The Android devices for example automatically try to use DoT to talk to the DNS IP address provided by DHCP and RA (the router IP address) and in turn uses DoT when talking to unbound. On Windows clients, that is also possible, but manual configuration change is needed (netsh dns add encryption server=<ip-address> dothost=: autoupgrade=yes udpfallback=yes).
Container RAM usage stabilizes to about 37MB after a few days on ARM64 with the unbound configuration below:
server:
qname-minimisation: yes
interface: 0.0.0.0
interface: 0.0.0.0@853
interface: ::0
interface: ::0@853
access-control: 0.0.0.0/0 allow
access-control: ::/0 allow
num-threads: 2
tls-system-cert: yes
tls-service-key: "/etc/unbound/unbound.key"
tls-service-pem: "/etc/unbound/unbound.pem"
unblock-lan-zones: yes
insecure-lan-zones: yes
serve-expired: yes
serve-expired-client-timeout: 0
private-domain: lan.
forward-zone:
name: "lan."
forward-addr: <router-ip-on-container-bridge>
forward-zone:
name: "in-addr.arpa."
forward-addr: <router-ip-on-container-bridge>
forward-zone:
name: "ip6.arpa."
forward-addr: <router-ip-on-container-bridge>
forward-zone:
name: "."
forward-tls-upstream: yes
forward-addr: 2606:4700:4700::1111@853#cloudflare-dns.com
forward-addr: 2606:4700:4700::1001@853#cloudflare-dns.com
forward-addr: 1.1.1.1@853#cloudflare-dns.com
forward-addr: 1.0.0.1@853#cloudflare-dns.com
I now only use MikroTik's DoH implementation on the devices with low available resources (like the hAP ac²) or without container support like the old hEX.