I’m using a Let’s Encrypt wildcard certificate from one of my domains to provide HTTPS access to both the RouterOS admin interface and Hotspot login pages.
With the admin interface, the certificate works just fine, however when connecting to the hotspot from an Android device, it displays an error that the certificate is not trusted. I’ve configured the hotspot to use a DNS name within that domain, but the Android client still reports that the certificate is not trusted. If I open the hotspot page in Chrome, the error is that the CA is invalid.
When connecting to the Webfig interface over HTTPS from https://router.domain.com (which internal DNS resolves to its LAN IP, but is also accessible from trusted external networks through a public IP), this works fine with no certificate errors, so I don’t believe anything to be wrong with the certificate.
Example:
Let’s Encrypt cert is issued *.domain.com with *.domain.com and domain.com as subject alternate names
RouterOS hotspot address is the router IP on that VLAN 10.9.0.254, DNS name is guestlogin.domain.com
Edited to add: I was originally using the .crt file directly as provided from Let’s Encrypt, but I have also tried a .der certificate which contains the full chain, including CA certs as the absence of the full chain was previously causing an issue for email clients on Android.
I have tried a Windows 10 client and this does NOT cause a certificate error, so appears to be specific to Android. Has anyone seen and worked around/resolved this?
/ip hotspot walled-garden ip add action=accept disabled=no dst-address=ocsp.int-x3.letsencrypt.org server=hotspot1
value of range must have ip address before ‘-’
I added the two IPv4 addresses resolved from that host in separate rules, but didn’t seem to have any effect.
I also tried adding the IP address for https://status.umbrella.com and then accessing that page, but was still being redirected to the hotspot login page (with associated warning that the cert for status.umbrella.com was from my hotspot), so i don’t think adding that to the walled garden is working as expected.
The DNS IP address issued by DHCP to the hotspot clients is external, if that makes any difference (208.67.222.222/208.67.220.220)
I found reports from another forum for a Cisco product having a similar issue with Android clients and it was indeed related to redirecting access to the CRL/OCSP
I added 2 x rules in the Walled Garden IP list for the 2 x DNS addresses. Limiting to a destination of UDP/53 didn’t work, so I just allowed any traffic to those IPs.
I then re-added the rule with a destination host of ocsp.int-x3.letsencrypt.org - I can then browse to https://ocsp.int-x3.letsencrypt.org in Chrome before logging in to hotspot, though it returns an error from the web server - possibly expected.
I’m still getting the certificate error though.
The previous post from eworm was close to the solution but not quite, as adding that URL didn’t work for me.
There followed a combination of trial and error along with running a mirror port on my switch to capture traffic (particularly DNS and HTTP) and see what requests were being made/intercepted.
The client was actually trying to fetch a URL of cert.int-x3.letsencrypt.org and I actually needed to add the URL under Walled Garden (not Walled Garden IP List). That got it working with no certificate errors (and I’d also removed the DNS IPs from the walled garden IP list at this point).
However, I then did some further investigation around that URL and discovered that it was just fetching the intermediate cert and nothing to do with revocation lists or OSCP, which I confirmed by then checking the AIA field in the cert, having understood how to do so.The OSCP URL provided by eworm was in fact correct, but that wasn’t what the client was trying to fetch, hence not resolving the issue.
Although the certificate I had uploaded to RouterOS contained the full chain, it appeared not to be in a format that RouterOS could decipher that full chain, so it wasn’t sending the intermediate to the client and therefore the client was trying to use the AIA info to fetch the intermediate cert, which is what I was allowing above. Having re-uploaded the certificate to RouterOS as a full chain including the private key in the same file in PEM format (confirmed by the fact I now see two certificates in RouterOS instead of one), this is now working in all browsers - without the need to allow either of the URLs in the cert’s AIA field in the walled garden.
Edited this post a few times rather than posting multiple times with developments and re-wording for clarity.