Dears , Hope you are doing well , I tried to deploy DANE at my testing environment and do the following :-
1) Create self-signed certificate "IDN domain name".
2) Get the TLSA hash from self-signed certificate file.
3) Add the TLSA record to zone file. And when I try to execute dig @8.8.8.8mailto: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. The TLSA validator said that :-
[cid:image008.jpg@01D0BDC0.1A30F150]
, any advice !!!
Thnx
All the Best, Abdalmonem Tharwat Galila Deputy Manager, Dot Masr Registry, Operation Sector.
[Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: https://fbcdn-sphotos-h-a.akamaihd.net/hphotos-ak-ash4/268513_18015288870764...]
National Telecommunication Regulatory Authority [Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: 1365523405_telephone] Office Tel.: +2 02 35341582 - +2 02 35341300 [Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Mobile] Mobile: +2 010 0049068 [Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: ICON] Fax : +2 02 35370537 [Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: oNLINE] Website: http:\www.mcit.gov.eghttp://www.mcit.gov.eg/ : http:\www.tra.gov.eghttp://www.mcit.gov.eg/ [Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: 1365523294_email] E-mail :agalila@mcit.gov.egmailto:agalila@mcit.gov.eg :atharwat@tra.gov.egmailto:atharwat@tra.gov.eg
[Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: 1365523469_error]DISCLAIMER This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please notify your system support manager. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the National Telecom Regulatory Authority (NTRA) . Finally, the recipient should check this email and any attachments for the presence of viruses. The NTRA accepts no liability for any damage caused by any virus transmitted by this email.
On Mon, Jul 13, 2015 at 09:04:34PM +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 TLSA validator said that :-
[cid:image008.jpg@01D0BDC0.1A30F150]
any advice !!!
The correct "3 0 1" TLSA for your server is:
_443._tcp.xn----ymcadjpj1at5o.xn--wgbh1c. TLSA 3 0 1 AD562370D03DFBE4EDFC4780A2367C8FD086D8A00D53A80D8EC6A8909D50DA9A
What you've published is:
_443._tcp.xn----ymcadjpj1at5o.xn--wgbh1c. TLSA 3 0 1 1A70DF05AC43318AB35A16542A8736D077ACE3126FAFE00508EDD7484F293C6C
No idea what that is the digest of, but it is not the digest of the DER form of the server certificate.
Dear Viktor Dukhovni , 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. Thnx
-----Original Message----- From: dane-users-bounces@sys4.de [mailto:dane-users-bounces@sys4.de] On Behalf Of Viktor Dukhovni Sent: Tuesday, July 14, 2015 6:58 AM To: dane-users@sys4.de Subject: Re: TLSA Validation Failed
On Mon, Jul 13, 2015 at 09:04:34PM +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 TLSA validator said that :-
[cid:image008.jpg@01D0BDC0.1A30F150]
any advice !!!
The correct "3 0 1" TLSA for your server is:
_443._tcp.xn----ymcadjpj1at5o.xn--wgbh1c. TLSA 3 0 1 AD562370D03DFBE4EDFC4780A2367C8FD086D8A00D53A80D8EC6A8909D50DA9A
What you've published is:
_443._tcp.xn----ymcadjpj1at5o.xn--wgbh1c. TLSA 3 0 1 1A70DF05AC43318AB35A16542A8736D077ACE3126FAFE00508EDD7484F293C6C
No idea what that is the digest of, but it is not the digest of the DER form of the server certificate.
Am 14.07.2015 um 10:37 schrieb Abdelmeniem Tharwat:
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
I use ldns from https://www.nlnetlabs.nl/projects/ldns/
ldns-dane -c /path/to/cert.pem create $(FQDN) $(PORT) 3 1 1
Dear Mark , Thanks for your response , actually I am asked about how Viktor generate the TLSA record "The Correct" ? as my problem was in the record Generated by openssl command which is like what you sent to me "Same TLSA record". It is working now , but may Viktor have a time to send me how he generated the TLSA record ? Thanks
-----Original Message----- From: dane-users-bounces@sys4.de [mailto:dane-users-bounces@sys4.de] On Behalf Of Abdelmeniem Tharwat Sent: Tuesday, July 14, 2015 11:37 AM To: 'dane-users@sys4.de' Subject: RE: TLSA Validation Failed
Dear Viktor Dukhovni , 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. Thnx
-----Original Message----- From: dane-users-bounces@sys4.de [mailto:dane-users-bounces@sys4.de] On Behalf Of Viktor Dukhovni Sent: Tuesday, July 14, 2015 6:58 AM To: dane-users@sys4.de Subject: Re: TLSA Validation Failed
On Mon, Jul 13, 2015 at 09:04:34PM +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 TLSA validator said that :-
[cid:image008.jpg@01D0BDC0.1A30F150]
any advice !!!
The correct "3 0 1" TLSA for your server is:
_443._tcp.xn----ymcadjpj1at5o.xn--wgbh1c. TLSA 3 0 1 AD562370D03DFBE4EDFC4780A2367C8FD086D8A00D53A80D8EC6A8909D50DA9A
What you've published is:
_443._tcp.xn----ymcadjpj1at5o.xn--wgbh1c. TLSA 3 0 1 1A70DF05AC43318AB35A16542A8736D077ACE3126FAFE00508EDD7484F293C6C
No idea what that is the digest of, but it is not the digest of the DER form of the server certificate.
He probably used
openssl s_client -connect xn----ymcadjpj1at5o.xn--wgbh1c:443 | openssl x509 -outform der | openssl sha256
Am 14.07.2015 um 12:05 schrieb Abdelmeniem Tharwat:
Dear Mark , Thanks for your response , actually I am asked about how Viktor generate the TLSA record "The Correct" ? as my problem was in the record Generated by openssl command which is like what you sent to me "Same TLSA record". It is working now , but may Viktor have a time to send me how he generated the TLSA record ? Thanks
I presume he connected to your SSL protected website directly - using openssl.... (almost a replacement for "telnet xn----ymcadjpj1at5o.xn--wgbh1c 443")
# openssl s_client -connect xn----ymcadjpj1at5o.xn--wgbh1c:443
Then - echo the server certificate part.... through the commands I gave earlier....
echo "-----BEGIN CERTIFICATE-----
MIIDXzCCAkegAwIBAgIEC51NfTANBgkqhkiG9w0BAQsFADBgMQkwBwYDVQQGEwAx
[bit in the middle deleted due to 40K limit of message size]
BXBpup6UrH+A4ikdAV+H2HKUwtLOtywjxcpKEPAOmAaGsnt0JwlTNJyyupEO6dCf 3xnY -----END CERTIFICATE----- " | openssl x509 -outform DER | openssl sha256
(stdin)= ad562370d03dfbe4edfc4780a2367c8fd086d8a00d53a80d8ec6a8909d50da9a
or equally do this all in one step - but I think this may actually "hide" too much of the logic of what happens...
# openssl s_client -connect xn----ymcadjpj1at5o.xn--wgbh1c:443 | openssl x509 -outform DER | openssl sha256
:-)
On Tue, 2015-07-14 at 10:05 +0000, Abdelmeniem Tharwat wrote:
Dear Mark , Thanks for your response , actually I am asked about how Viktor generate the TLSA record "The Correct" ? as my problem was in the record Generated by openssl command which is like what you sent to me "Same TLSA record". It is working now , but may Viktor have a time to send me how he generated the TLSA record ? Thanks
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 1 AD562370D03DFBE4EDFC4780A2367C8FD086D8A00D53A80D8EC6A8909D50DA9AWhat you've published is:
_443._tcp.xn----ymcadjpj1at5o.xn--wgbh1c. TLSA 3 0 1 1A70DF05AC43318AB35A16542A8736D077ACE3126FAFE00508EDD7484F293C6CNo 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
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
If Viktor speaks about TLSA/DANE - you should probably believe him.... :-)
The way I create the TLSA 3 0 1 from a WEB certificate is:
cat cert.crt | openssl x509 -outform DER | openssl sha256
ie - the input is the ".crt" file.....
For reference purposes... For email - you need a TLSA 311 Certificate.
cat cert.crt | openssl x509 -noout -pubkey | openssl pkey -pubin -outform DER | openssl sha256
(all one line)
Mark Elkins mje@posix.co.za writes:
For email - you need a TLSA 311 Certificate.
Care to explain why? I am sure I'm missing something here, but this isn't obvious to me.
And does "email" mean SMTP or POP/IMAP or all of them?
Until now I've just used the same private self-signed CA certificate for all services, and just created aliases to a common TLSA 2 0 1 record. This appeared to work fine, but then again: I don't know how I would detect a failure... There aren't that many validating email clients out there.
How do you test and validate TLSA records for SMTP, POP and IMAP?
Bjørn
(Please correct me if I am wrong - Still Learning myself!)
On Tue, 2015-07-28 at 15:34 +0200, Bjørn Mork wrote:
Mark Elkins mje@posix.co.za writes:
For email - you need a TLSA 311 Certificate.
Care to explain why? I am sure I'm missing something here, but this isn't obvious to me.
The topic was DANE and generating valid TLSA records from a Web certificate for Web purposes. The same Web Certificate can be used for creating an appropriate TLSA certificate for Mail. In the case of MTA to MTA (Mail Transport Agent, eg for use by exim or Postfix) - the TLSA certificate could look like...
_25._tcp.vweb.co.za. IN TLSA 3 1 1 588c9c64a52c1a0d4cb1e82d67d746504241480c55b1edd24b6fc7cd 4f836997
ie - the bit you stick in a zone file....
And does "email" mean SMTP or POP/IMAP or all of them?
Just MTA to MTA
Until now I've just used the same private self-signed CA certificate for all services,
In my experience, most web browsers complain about self-signed certificates, until an exception is made of that Certificate. Microsoft Explorer is particularly rude and strongly suggests a user not to trust it ( = Customers go elsewhere). I think therefore to make going to a secure website as palatable as possible, get the Certificate signed by a reputable CA. If you have such a certificate - it can be used also for e-mail, for MTU to MTU (Secure-SMTP), for Submission (Authenticated+Secured SMTP) and for IMAP/POP3 (eg courier-imap stuff).
and just created aliases to a common TLSA 2 0 1 record. This appeared to work fine, but then again: I don't know how I would detect a failure... There aren't that many validating email clients out there.
I think Viktor Dukhovni ietf-dane@dukhovni.org possible has a test system?
How do you test and validate TLSA records for SMTP, POP and IMAP?
If by SMTP, you mean a client sending outbound mail via their ISP using Submission - I wasn't aware that TLSA records played a role in this area. I'm also not aware that they play a role in the IMAP/POP3 area either.
I personally use IMAP on port 993 (SSL/TLS) and Submission on 587 (STARTSSL after Connection) - and have done a long time before playing with DANE and TLSA records.
TLSA Records for MTU to MTU makes sense - you don't know if the recipient MTA uses TLS, the TLSA in the (DNSSEC Secured) DNS can confirm this if it exists.
On the other hand, the relationship between Client and ISP by definition probably has to be known about. (I run a smallish ISP - I have clients, many of them have their mail clients configured like this.)
Bjørn
On Tue, Jul 28, 2015 at 03:34:23PM +0200, Bj?rn Mork wrote:
Mark Elkins mje@posix.co.za writes:
For email - you need a TLSA 311 Certificate.
Care to explain why? I am sure I'm missing something here, but this isn't obvious to me.
And does "email" mean SMTP or POP/IMAP or all of them?
Sorry, just MTA-to-MTA SMTP:
https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-19#section-1.3
Until now I've just used the same private self-signed CA certificate for all services, and just created aliases to a common TLSA 2 0 1 record.
That's also fine, if the CA in question is the issuer of the individual server certificates. The constraint for MTA-to-MTA SMTP is that you SHOULD NOT publish TLSA records with certificate usages PKIX-TA(0) or PKIX-EE(1). A "3 X Y" is the right alternative for "1 X Y" and "2 N M" is the right alternative for "0 N M".
https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-19#section-3.1.1 https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-19#section-3.1.2 https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-19#section-3.1.3 https://tools.ietf.org/html/draft-ietf-dane-ops-14#section-5.1 https://tools.ietf.org/html/draft-ietf-dane-ops-14#section-5.2 https://tools.ietf.org/html/draft-ietf-dane-ops-14#section-5.3 https://tools.ietf.org/html/draft-ietf-dane-ops-14#section-5.4
This appeared to work fine, but then again: I don't know how I would detect a failure... There aren't that many validating email clients out there.
How do you test and validate TLSA records for SMTP, POP and IMAP?
Just for SMTP MTAs (port 25):
participants (6)
-
Abdelmeniem Tharwat -
Andreas Schulze -
Bjørn Mork -
Mark Elkins -
sys4＠arcsin.de -
Viktor Dukhovni