# certbot certonly -d delphi-real-estate.com,www.delphi-real-estate.com,mail.delphi-real-estate.com
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Error while running apachectl configtest.
AH00526: Syntax error on line 64 of /etc/httpd/conf.d/carls-vhosts.conf:
SSLCertificateFile: file '/etc/letsencrypt/live/delphi-real-estate.com/cert.pem' does not exist or is empty
How would you like to authenticate with the ACME CA?
-------------------------------------------------------------------------------
1: Apache Web Server plugin - Beta (apache) [Misconfigured]
2: Spin up a temporary webserver (standalone)
3: Place files in webroot directory (webroot)
-------------------------------------------------------------------------------
Select the appropriate number [1-3] then [enter] (press 'c' to cancel): 2
Plugins selected: Authenticator standalone, Installer None
Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
Obtaining a new certificate
Performing the following challenges:
tls-sni-01 challenge for delphi-real-estate.com
tls-sni-01 challenge for www.delphi-real-estate.com
tls-sni-01 challenge for mail.delphi-real-estate.com
Waiting for verification...
Cleaning up challenges
Failed authorization procedure. mail.delphi-real-estate.com (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: DNS problem: SERVFAIL looking up A for mail.delphi-real-estate.com, www.delphi-real-estate.com (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: DNS problem: SERVFAIL looking up A for www.delphi-real-estate.com, delphi-real-estate.com (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: DNS problem: SERVFAIL looking up A for delphi-real-estate.com
IMPORTANT NOTES:
- The following errors were reported by the server:
Domain: mail.delphi-real-estate.com
Type: connection
Detail: DNS problem: SERVFAIL looking up A for
mail.delphi-real-estate.com
Domain: www.delphi-real-estate.com
Type: connection
Detail: DNS problem: SERVFAIL looking up A for
www.delphi-real-estate.com
Domain: delphi-real-estate.com
Type: connection
Detail: DNS problem: SERVFAIL looking up A for
delphi-real-estate.com
To fix these errors, please make sure that your domain name was
entered correctly and the DNS A/AAAA record(s) for that domain
contain(s) the right IP address. Additionally, please check that
your computer has a publicly routable IP address and that no
firewalls are preventing the server from communicating with the
client. If you're using the webroot plugin, you should also verify
that you are serving files from the webroot path you provided.
************************************************************************
Well it comes up fine when pinging, on all three names.
DNSStuff finds everything is fine (except it can’t connect to port 25 which is understandable).
If you try to query it using DNSSEC-validating resolver (such as Google Public DNS), you'll get SERVFAIL errors. You can also use https://unboundtest.com/, which is configured to mimic Let's Encrypt validation servers.
I’m no DNSSEC expert, but this is going to cause issues with issuance regardless of cause. Let’s Encrypt handles DNS lookups slightly differently, but in general, if it fails on Google’s DNS, it’s probably going to have issues with Let’s Encrypt. (Note that the inverse is not necessarily true.)
I don’t understand what G**gle nor LetsEncrypt wants. I don’t know what more to do than to set it up correctly at a major DNS registrar, and exactly like I set up the other domains which got LE certs.
It is simply not a DNSSEC problem, unless it’s that G**gle and LetsEncrypt -require- DNSSEC.
And then it’s an impossible catch 22.
@Quantum, but there IS a problem with DNSSEC at your domain. Nameservers for .com domain claim that your domain has DS record set:
[mkwm]:~$ dig DS delphi-real-estate.com @a.gtld-servers.net
; <<>> DiG 9.9.10-P2 <<>> DS delphi-real-estate.com @a.gtld-servers.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33355
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 27
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;delphi-real-estate.com. IN DS
;; ANSWER SECTION:
delphi-real-estate.com. 86400 IN DS 1 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32 F24E8FB5
;; AUTHORITY SECTION:
com. 172800 IN NS f.gtld-servers.net.
com. 172800 IN NS d.gtld-servers.net.
com. 172800 IN NS g.gtld-servers.net.
com. 172800 IN NS m.gtld-servers.net.
com. 172800 IN NS j.gtld-servers.net.
com. 172800 IN NS a.gtld-servers.net.
com. 172800 IN NS l.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
com. 172800 IN NS k.gtld-servers.net.
com. 172800 IN NS h.gtld-servers.net.
com. 172800 IN NS i.gtld-servers.net.
com. 172800 IN NS e.gtld-servers.net.
com. 172800 IN NS c.gtld-servers.net.
If you have disabled DNSSEC at your registrar, this record should disappear... But it is still present, not sure why... Maybe it's a bug at the registrar side?
To clear up any confusion - DS record is a bit different from the others, as it is placed inside parent zone (com in your case), instead of directly inside your zone (delphi-real-estate.com). This means it requires special handling by your domain registrar (just like with changing NS records).
Your search for delphi-real-estate.com returns the below results:
Domain Name: DELPHI-REAL-ESTATE.COM
Registry Domain ID: 1736975196_DOMAIN_COM-VRSN
Registrar WHOIS Server: whois.gkg.net
Registrar URL: http://www.gkg.net
Updated Date: 2017-11-18T18:56:44Z
Creation Date: 2012-08-02T18:24:33Z
Registry Expiry Date: 2019-08-02T18:24:33Z
Registrar: GKG.Net, Inc.
Registrar IANA ID: 93
Registrar Abuse Contact Email: abuse@gkg.net
Registrar Abuse Contact Phone: +1.8776951790
Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited
Name Server: NS3.GKG.NET
Name Server: NS4.GKG.NET
DNSSEC: signedDelegation
DNSSEC DS Data: 1 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5
URL of the ICANN Whois Inaccuracy Complaint Form: https://www.icann.org/wicf/
>>> Last update of whois database: 2017-11-21T22:55:22Z <<<
So, something clearly went wrong with disabling DNSSEC (DNSSEC: signedDelegation shouldn’t be there). I guess waiting would not help (as this is not a problem with DNS propagation)
I’ve heard back from my registrar, and I don’t understand why delphi-real-estate.com was represented as DNSSEC (as opposed to the others), but to solve it he just turned DNSSEC on. His explanation isn’t clear, but I now have my delphi cert and all domains are now cranking.
“_After reviewing your domain configurations, The domain was not signed with DNSSEC, even though you had your Delegation Signer Records. By turning on DNSSEC is the DNS Configuration panel, it added the DNSKEY and RRSIGs to the domain. And synchronized properly. I was able to verify that DNSSEC is working through verisignlab’s DNSSEC debugger, you can also check with the link below. _
_DNSSEC Analyzer
Somehow he’s enabled DNSSEC – I’d thought that DNSSEC required the domain’s cert, but I haven’t gotten to that part yet so maybe I’m wrong.
Nope, DNSSEC is a parallel system of validating domain name ownership. You are probably thinking of DANE, which is an additional system on top of DNSSEC that can express requirements about the domain's certificate. DANE is not implemented by browsers, so if your goal is securing a web site, it's probably not of interest to you.
Ah yes, DANE for email. Fortunately my registrar has a tab for TLSA. I’ll get to that at some point.
There’s a DANE plugin for Firefox, but I’m a bit wary of plugins. I’ll probably try out Bloodhound at some point. Hopefully Tor Broweser and Firefox will integrate the DANE patches soon.
What’s the use of DANE? DNSSEC makes sure that you get the correct IP address when you want to connect, while a DANE TLSA record (signed by DNSSEC) will give information about the SSL/TLS certificate you can expect at the specific service you are connecting to. This way you don’t have the (usual) plaintext exchange for initial authentication.
And needless to say, in using a trusted root CA like LE, your SMTPs server is much less likely to be thought carrying spam. And this will at least encrypt on the uplink and downlink with perfect forward secrecy, and depending on intermediate servers may remain encrypted through each transit hop.
It’s easy when your registrar supports it. I have a TLSA tab in Modify domains. Add a record and set
Port 443
Protocol tcp
Host @
Cert Usage 3.DANE-EE
Selector 1.SPKI
Match 2.SHA2-512
TTL 1 day
Then you need a SHA512 hash of the public cert: This site makes it easy: https://www.huque.com/bin/gen_tlsa
Or, you could use the sha512sum command, but you’d need to remove all the {CR}s from the cert first.
This sets your TLSA record for the website. You can also add TLSA records for email by doing all the same, but for ports 587 and 993. Be sure to set the domain here for mail.{mydomain}.com if that’s what you use.
