Hi all, As an extension of this topic with the same title: https://www.howtoforge.com/community/threads/soa-serial-number-format-is-invalid.76324/ I too am having this warning from MXToolbox.com: "SOA Serial Number Format is Invalid" I understand that the serial number should be a backwards date followed by 2 digits, ie: 2018080601 and ISPConfig appears to be doing this fine (see image), so why the error? I'm also getting some more errors which I do not know where to start looking: Reverse DNS does not match SMTP Banner - this has something to do with what my ISP is naming my public IP hostname, is that right? What should it be, exactly? What should the format be? 9.036 seconds - Not good! on Transaction Time - Why so slow? This is a fresh install with no load on the VM at all. At least one name server failed to respond in a timely manner SOA Expire Value out of recommended range - what effect will this have if it's 7 days or 14 days? Why the preference? Thanks in advance for your help!
1. SOA - could be because you have 2 NS that do not know of each other -> see https://intodns.com/forefronttelco.com.au 2. Ask at your ISP to change PTR record with your server hostname I think that all the info you need to correct is at the above link.
Thanks Ghostdare. I will that link and see what I can do. I will report back on the SOA issue. I have contacted my ISP and they are going to change the PTR record which will fix that issue, thank you very much for that tip! Anyone got any ideas on the other issues? 1) 9.036 seconds - Not good! on Transaction Time - Why so slow? This is a fresh install with no load on the VM at all. 2) At least one name server failed to respond in a timely manner 3) SOA Expire Value out of recommended range - what effect will this have if it's 7 days or 14 days? Why the preference?
I'm not clear if it's smtp or dns that you're timing. DNS and everything else can be slow when you have a DNS problem (which you do, as per "2)"). SMTP could be slow for that or other reasons (including an intentional delay in the initial greeting if you're using postscreen); I'd guess DNS is the first likely culprit, but also check if your mysql is answering promptly (which itself could be delayed if you have DNS problems). In a quick test, ns1 answers dns queries, ns2 does not. The expire value is how long a slave server will retain the zone info when it can't reach the master, so the effect of changing it is if you use a master/slave setup (which is common, but fwiw ISPConfig mirrored servers do not), and the slave can't reach the primary to refresh the zone info and make sure the slave copy is up to date, it will delete the zone after either 7 or 14 days.
certbot has a --cert-name option to use for this, so you can always keep the same certificate name even when requesting certificates with different subsets of hostnames (ie. prevents the -001, -002, etc. certificate names).
This option does not exist in older certbot versions, that's why we could not use that at the time we implemented the function.
no, though it is off-topic for your question - it pertains to till's comment there (a solution to the changing certificate name problem, where supported)
