Thanks a lot vector.
-----Original Message----- From: dane-users-bounces@sys4.de [mailto:dane-users-bounces@sys4.de] On Behalf Of Viktor Dukhovni Sent: Tuesday, July 14, 2015 7:08 PM To: dane-users@sys4.de Subject: Re: TLSA Validation Failed
On Tue, Jul 14, 2015 at 08:37:10AM +0000, Abdelmeniem Tharwat wrote:
And when I try to execute dig @8.8.8.8 _443._tcp.xn----ymcadjpj1at5o.xn--wgbh1c +dnssec TLSA, I got the TLSA record that is identical to the hash from crt file.
Both are wrong.
The correct "3 0 1" TLSA for your server is:
_443._tcp.xn----ymcadjpj1at5o.xn--wgbh1c. TLSA 3 0 1AD562370D03DFBE4EDFC4780A2367C8FD086D8A00D53A80D8EC6A8909D50DA9A
What you've published is:
_443._tcp.xn----ymcadjpj1at5o.xn--wgbh1c. TLSA 3 0 11A70DF05AC43318AB35A16542A8736D077ACE3126FAFE00508EDD7484F293C6C
No idea what that is the digest of, but it is not the digest of the DER form of the server certificate.
You are right, but kindly advice how can I get the TLSA record? I used
openssl x509 -in xn----ymcadjpj1at5o.xn--wgbh1c.registry.crt -outform DER | openssl sha256 (stdin)= 1a70df05ac43318ab35a16542a8736d077ace3126fafe00508edd7484f293c6c
And got what I did add to zone file.
Then the file you used is not the certificate used by the actual Internet-facing webserver. Perhaps you forgot to reconfigure the server.
Also, its self-signed certificate has a rather short lifetime, I would suggest a lifetime of 10 years or more, which is invalidated by updating the TLSA record, not the underlying expiration.
You might find my "tlsagen" bash script handy.
$ ~/tlsagen xn----ymcadjpj1at5o.xn--wgbh1c.pem xn----ymcadjpj1at5o.xn--wgbh1c:443 3 0 1 _443._tcp.xn----ymcadjpj1at5o.xn--wgbh1c. IN TLSA 3 0 1 AD562370D03DFBE4EDFC4780A2367C8FD086D8A00D53A80D8EC6A8909D50DA9A