If Exchange should really require 128 GB RAM, that customer is out of the game anyway
That was basically our thought process. I checked around a bit and some people with smaller servers said Exchange 2019 seemed to be OK with 64 or 92 but in the big picture I think Microsoft expects enterprises to run their own servers, and everyone else to use 365.
re: maintenance, Microsoft only releases security updates for supported versions of Exchange which is the last two Cumulative Updates of each version. This MS page is noisy but if you look closely only the Exchange 2016 CU22 and CU23 lines have links because they are supported, and CU21 has no updates after March. Essentially, every 3-6 months one must install a CU which in my experience takes 2-3 hours because it's essentially a full Exchange install each time. If someone isn't installing those, no security updates for Exchange are installed via Windows Update. It just quietly doesn't see any.
Exchange 2016 ends support in Oct. 2025. Microsoft only allows/supports migrations for the prior two versions. So your customer will need to move to Exchange 2019 or "Exchange 2022" or whatever it will be called by 2025.
None of that is anywhere near your question but that's why we moved off local hosting, and none of it is our problem anymore. :)
I asked the same question over in the Let’s Encrypt forums, and I got some great answered and clarification on what I was trying to do. https://community.letsencrypt.org/t/acmev2-ssl-with-google/187727/18
Hopefully Google will do ACME wildcard verification through Google Domains in the future.
page, and start reading.
This time, up until the bottom.
You will find the very important dns sleep.
That's why it's there.
And also this one :
as it was made for you.
The certificate name will not change when it is renewed. No need to select 'another' cert in the HA Proxy settings.
Now, when acme.sh successfully renewed the certificate, it will also restart HAproxy. So it takes in account the renewed certificate.
And you can go back to the admin's main task : constantly ( 😊 ) checking if all automated tasks are correctly executed.
I don't expose the GUI to the WAN, and frankly I have little need for SSL to my pfSense beyond getting rid of the annoying "Invalid SSL Cert" interstitial page when logging in from an internal machine. Using "dave.duckdns.org" internally works nicely for this, solving my problem.
@gregoinc I just went through this myself. I originally had made all my own certs and added them to clients root cert authority but the self hosted web interface for my home security system doesn't allow for adding of ssl certs. Since I already have a paid for domain name for 10 years and this was so easy I just set it up for all my home private severs on LAN. I know I'm about a month late, but for anyone else maybe it will help. YouTube: How To Create pfsense Let's Encrypt Wildcard Certificates using HAProxy
In dns manual mode, after the dns record is added manually, acme.sh will use cloudflare public dns ....
as cloudflare public dns or google dns are only used when dnssleep is not set.
dnssleep is pretty mandatory when using some API/auto mode.
But not for manual mode (human interaction is slow by default ;) )
dnssleep exists because DNS syncing takes an unknown time.
The DNSAPI mode uses a script file and your access credentials so you it can add (and afterwards : remove) one or more TXT records. You will be updating the DNS domain name master DNS only. There should be at least one DNS slave, and it will get signalled 'by the master there is an update' in the zone.
The zone slave can then initiate a zone transfer whenever it wants, it could be right away, or x second / minutes later (the zone master admin determines the sync parameters).
When the zone is synced, LE is signalled to proceed with zone checking. It will locate the domain name servers, pick any of them, and checks the TXT record.
Btw : I thinks it checks all the listed name servers.
When using manual mode, there is no need to wait ..... sleep == dnssleep, as it will take you some time to connect to the GUI that allows you to set the needed TXT records in your domain zone
Because you didn't use dnssleep acme.sh will do now an extra step for you when you proceed : it will do a dns zone check for you by using cloudfare, google DNS etc.
So acme.sh will only signal LE to proceed with the zone checking if it knows that the TXT records are actually set (and the admin who sets the TXT records manually didn't make a mistake).
I don't understand why this check isn't actually made also when DNSAPI mod is used, as an extra local check step before LE is asked to check and deliver a cert.
My for some sites where acme.sh is used there is no google or cloudfaire access ( pfblockerng users ;) )
the purpose of the field is not to "configure how much time to wait before attempting verification" but rather it's to disable verification and instead wait the specified numbers of seconds. This is useful for people like me that block access to cloudflare and google DNS.
Well, it is waiting xxx seconds after a "successful TXT field insertion".
During this time, DNS master and slave(s) should do their sync magic.
Then control is given back to LE so it can do its checking, and give you back a cert if it was successful.
I guess this dnssleep parameters serves somehow a double function.
When absent (not set) acme.sh will do a local check using a known DNS resolvers. I tend to say : to inform you that you did your manual work ok.
IMHO :the ddnssleep can be very low, but can't be zero in 99,99 % of all cases.
It should be set to "120" if you didn't modify that setting.
Btw : I'm using nsupdate ( dns_nsupdate.sh ) method as I do not use the API of my registrar : I'm hosting my own domain name master and several domain name slaves (bind). These domain name servers only host my own domain names, so they have not much to do.
I can follow the update process while tracing the logs everywhere = the adding of the two TXT records, the signalling of the master to the slave, the reception of this signal by the slaves, the slaves that call back the master for a zone sync.
One in a while, I also use freedns.afraid.org as an extra dns slave, and the sync back of freedns can take to up to 5 minutes to sync with my master. When I use the dns salves of my registrar, this can even take longer, as they have zillions of zones (domain names) to handle.
While creating a certificate for HAProxy I am seeing some strange behaviour in the DNS-Simply.com validation.
I have few domains under different accounts at simply.com
Let's call them domain1.com and domain2.com.
domain1.com with it's own account name and API key
domain2.com with it's own account name and API key
When issuing the certificate it fails immediately with domain1.com but using credentials from domain2.com which obviously doesn't contain DNS for domain1.com.
I can see it in the log that the URL is using the account name for domain2.com when trying to add the TXT record for _acme_challenge.domain1.com
Is this default behaviour or is there a bug?
Workaround was to create a certificate for each simply.com account and then do shared frontend in HAproxy.
@gertjan That's what I tought, that Cloudflare should have many users. Anyway I fixed it with removing all domains, saved and reentered everything. That fixed. Maybe the config file was broken, which was used to pass information.
@fmrc_cheeky Fair enough. Sounds like a different issue, as this was a fix specifically with the Netlify DNS provider API script, but basically you'll need to figure out a DNS provider that works with ACME, or use a different validation mechanism in this list: https://github.com/acmesh-official/acme.sh#supported-modes