Hey fellow network admins! 👋
So I've got this habit of keeping my MikroTik router updated to the latest firmware version. Usually, it's smooth sailing - upgrade, reboot, everything works perfectly. But recently, I hit a weird snag that had me scratching my head for a while.
The Problem Strikes
I just upgraded my MikroTik from version 7.18.2 to 7.19, expecting the usual seamless experience. Instead, my users suddenly couldn't browse the internet. Not exactly what you want to hear on a Monday morning! 😅
Time to fire up WinBox and see what's going on.
The Hunt Begins
After connecting to my router, I started digging through the logs and found this lovely error message repeating over and over:
DoH server connection error: SSL: ssl: no trusted CA certificate found (6)
Well, that's not good. DNS over HTTPS was basically throwing a tantrum about SSL certificates.
To make things even more interesting, when I tried to ping from the MikroTik terminal, I got this confusing output:
ping youtube.com
invalid value for argument address:
invalid value of mac-address, mac address required
invalid value for argument ipv6-address
Yeah, that's definitely not normal ping behavior.
Quick Fixes (That I Didn't Want to Use)
I found two quick workarounds:
- Switch to local DNS: Disabled DoH and used my ISP's DNS servers
- Disable certificate verification: Turn off DoH certificate verification
Both worked perfectly - no more errors, internet browsing was back to normal. But here's the thing: I wasn't comfortable with either solution. Using ISP DNS feels like giving up privacy, and disabling certificate verification? That's just asking for security troubles down the road.
The Real Solution: Certificate Management
My gut told me this was a certificate issue (thanks to that "no trusted CA certificate found" message). So I decided to tackle the root cause.
First Attempt: Import Standard Root CAs
I tried importing the standard certificate bundle from curl:
/tool fetch url=https://curl.se/ca/cacert.pem
/certificate import file-name=cacert.pem
Nope. Still getting the same SSL errors. Time for a more drastic approach.
Nuclear Option: Fresh Start with Google's Root CAs
⚠️ Warning: This next command will delete ALL certificates on your MikroTik. Make sure you know what you're doing!
/certificate remove [find]
Yep, I nuked all the certificates. Sometimes you just need a clean slate.
Then I imported Google's root certificate bundle:
/tool fetch url="https://pki.goog/roots.pem" dst-path="roots-goog.pem"
/certificate import file-name="roots-goog.pem"
And just like that... 🎉 IT WORKED!
Ping was back to normal, DoH was functioning properly, and my users could browse the internet again without any SSL certificate errors.
What Actually Happened?
Looking back, it seems like the upgrade to RouterOS 7.19 either corrupted or invalidated the existing certificate store. The built-in certificates that were working fine in 7.18.2 somehow became problematic in the new version.
By clearing out the old certificates and importing fresh root CAs from Google, I essentially gave the router a clean, trusted certificate foundation to work with.
Key Takeaways
- Certificate issues can be sneaky - They might not show up immediately after an upgrade
- Don't settle for insecure workarounds - Taking the time to fix the root cause is worth it
- Sometimes a nuclear approach is the fastest solution - Starting fresh with certificates can save hours of troubleshooting
- Keep backups - Always export your working certificate store before major upgrades (lesson learned!)
Pro Tips for Next Time
- Export your certificate store before upgrading:
/certificate export-certificate - Test DoH functionality immediately after firmware upgrades
- Keep a trusted root CA bundle handy for situations like this
- Document your certificate sources for easier troubleshooting
Have you run into similar certificate issues with MikroTik upgrades? Drop a comment below - I'd love to hear about your experiences and solutions!
Top comments (1)
There were no built-in certificates in 7.18.2 or before.
Mikrotik added those in 7.19, together with a bug that all existing (manually imported) certificates became unusable. You could make them usable again by deactivating and activating the certificates, or by deleting them and keeping the new embedded root CAs.