Hello, I have some important questions that a lot of people also and I would like to try to solve with you support, as I am having problems with ssl certificates and your answers can help everyone.
Important note: I use SSL certificates on Mikrotik devices for web browsing (https) in hotspot and always two days after correct installation and operation, I get certificate error with this message in the Logs: "got CRL with bad signature, issued by DST root CA X3 ::: Digital signature Trust Co. ::: "
Questions:
1- To work correctly Let’s Encrypt certificates must be generated through the same network and the same place where MikroTiK routers are installed or I can generate the certificates on a Linux server in the cloud with ACME installed and then copy the certificate and key to equipment elsewhere, in another datacenter, however, with the correct host name created and verified in the DNS TXT zone.
2 - To work correctly Let’s Encrypt certificates should devices (routers) be behind a dedicated (static) IP or can the IP be dynamic by DDNS with the use of CNAME in the DNS zone?
3- After verifying authenticity through the DNS TXT zone, do I also need to point to a FIXED IP of type DNS A or CNAME DNS or do not need?
4- Can I renew SSL certificates without having to confirm the host domain with DNS TXT again?
If yes, what the ACME command line?
Will Let’s Encrypt servers need to access devices or systems from time to time with SSL certificates installed to remain valid?
If yes, what are all the IPs (v4 and v6) and ports and protocols that we have to release on the firewall for verification to be allowed?
6- Is it possible to generate a certificate with many subdomains (example: * .mydomain.com) and put this same certificate on several devices and systems?
Thank you so much for your patience and your explanations.
That's weird... "DST Root CA X3" is a root operated by IdenTrust that signs the Let's Encrypt intermediates. As far as i know, they've never capitalized it "DST root CA X3". Is that a transcription error or is that what the error message said?
Root CRLs aren't even usually updated very frequently. (The current one in question is valid for 30 days, though i don't know how often it's replaced.)
I'd guess that the MikroTik's CRL software isn't configured to recognize DST Root CA X3 as a valid CA, or that it has a bug, but i dunno. You may need to ask MikroTik support.
Let's Encrypt doesn't inherently limit where you create or install certificates. Many ACME clients only (conveniently) support certain environments, but the CA doesn't inherently care. You can run a client on one server, copy the HTTP-01 challenge file to a second server for validation, and copy the certificate and key to a third server, if you wanted to. (certbot certonly --manual can do it, but it would be a very manual process, or require some scripting on your part. Some clients come with more built-in support.)
(HTTP-01 was only used as an example. It would be similar for DNS-01.)
Some hosting companies may limit what you can do with a certificate by keeping the private key from you, and some CAs may have restrictive licensing terms, but Let's Encrypt doesn't, and certificates and keys are just data structures in files, so you can copy them around to different computers if you want.
A more complicated setup may make it difficult to automate certificate renewal, though. And Let's Encrypt certificates expire every 90 days.
It doesn't matter. If using HTTP-01 or TLS-SNI-01 validation, the A/AAAA/CNAME record(s) have to function during the moments a validation is being performed, but beyond that it doesn't matter. For DNS-01, it never matters.
You wouldn't need any A, AAAA or CNAME records.
No. A validation can be reused for a certain amount of time (currently 30 days, but subject to change), but it will have expired long before you usually want to renew, so you'll have to validate all over again. When using DNS-01, that would mean setting a new TXT record with a different value. (HTTP-01 or TLS-SNI-01 would likewise require new values.)
No. Let's Encrypt only does anything during the moments when you're performing a validation (when creating or renewing a certificate). Outside of those seconds, the Let's Encrypt servers don't need to access your services.
For HTTP-01 and TLS-SNI-01 validation, Let's Encrypt needs to access your site on ports 80 and 443 respectively. For DNS-01, well, it just needs to be able to make the DNS queries.
The IPs of the validation servers are undisclosed and subject to change.
One certificate can have up to 100 names, from 1 or more domains. (example.com, www.example.com, www2.example.com, xyz.example.net...)
Let's Encrypt doesn't support wildcards certificates (*.example.com) but will starting in January.
You can copy a certificate to several computers if you want.
You can also issue a fairly large number of certificates, subject to the rate limits.
Hello,
I was also experiencing the "got CRL with bad signature, issued by DST root CA X3 ::: Digital signature Trust Co. :::" message in a log of my Mikrotik router. I was able to get rid of it by adding the IdenTrust DST root CA X3 certificate (downloaded at https://www.identrust.com/certificates/trustid/root-download-x3.html) to the router certificate store (see also Let’s Encrypt chain of trust page).
After that I got "CRL updated for <my_certificate_name>.crt_1" in my router log, which I believe is a mark of success.
You solved a mysterious problem. Congratulations. Now you have the latest and most complicated of them all.
All compatibility issues with Mikrotik have been resolved but this one I will report is what harms everyone. In mikrotik hot spot with SSL works well with bypass, without displaying certificate security failure message with Apple IOS, Windows Phone and Android, however when opening the authentication screen on any android that default to CHROME, it appears the message fault message. If opened by the android browser does not inform the possible problem of “fraud” (man in the middle). Is there any solution to give bypass equally to all others smartphones?
So it appears the user is trying to visit some other website and they are getting your login screen instead. This is what a captive portal does! But your login screen isn’t that website, so the user gets a security error.
Most new Android devices pop a notification in the top bar that allows you to sign in to wireless captive portals without accidentally hitting the security screen. Many other platforms have something similar.
For older devices that do not have this feature, there is nothing you can do to stop this besides not having a captive portal. You’ll have this problem on any platform where a user tries to visit a HTTPS URL first and they don’t have or bypass the captive portal detection.
If you’re in a position to help people, just tell them to visit example.com first (the official test server of the Internet). This site is available over plain HTTP and thus won’t cause certificate errors.
"DST Root CA X3" is a root operated by 
