Please explain/comment more on these:
Conventions, used in this email msg:
* The Beginning "%" symbol (and a space after it), is not used in
any real zone file. ( I have used this symbol used here for this
email post only, just to indicate a begin of a configuration line,
as, multiple time email reply can/may change position or remove
Line-Feed(LF/EOL) indicator ).
* Command-line will start with "$" symbol (and a space after it). Do
not use shown '$' when using in real command.
* When a command-line ("$ ") will show "\" symbol at-end, then bring
below one line after it, and remove the \ symbol. Here "\" symbol
is indicating "Next-Line is part of This Line".
I'm using such TLS / SSL Chain:
SSL / TLS Certificate Pyramid & Levels :
01 = Level-01 = is TA/Root-CA cert. (My_Root_CA.crt). Self-signed
new my own CA/TA cert.
02 = Level-02 = is an Intermediate CA cert. (My_i-CA.crt). under L-1.
03 = Level-03 = is an Intermediate Authority cert for dom1.tld.
(dom1_tld_IA.crt). It can only be used to create certs, only under
dom1.tld.
04 = Level-04 = is Server/EE-Certs : { s1.dom1.tld.crt,
s2.dom1.tld.crt, im.dom1.tld.crt, im2.dom1.tld.crt,
www.dom1.tld.crt, m.dom1.tld.crt }
TA = Trust Anchor . CA = Certificate Authority.
IA = Intermediate Authority.
cert = certificate. cert keypair. Both public key portion and
private key portion.
crt = cert's public (key) portion. can be shared.
key / prv.pem = private key portion of cert. do not share.
As a domain-owner, and an operator, etc ... i will be using my own
new self-signed TA (Trust Anchor) cert/bundle (aka, self-signed CA),
so i will need to do these, i understand this part:
% _443._tcp.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA
% _443._tcp.s1.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA
% _443._tcp.s2.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA
% _443._tcp.www.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA
% _443._tcp.m.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA
% _25._tcp.s1.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA
% _993._tcp.s1.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA
% _995._tcp.s1.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA
% _587._tcp.s1.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA
% _25._tcp.s2.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA
% _993._tcp.s2.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA
% _995._tcp.s2.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA
% _587._tcp.s2.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA
But when only TLSA TA "2 S M" is used, it is indicating, clients and
servers need to use multiple channels (port 80, port 443, port 53)
for related various purpose. :(
C_A_D = Certificate Association Data. Either a Raw/Binary Data,
DER-encoded full cert, when s=0 & m=0. Or, it can be a hash-code
(Base64-encoded) of raw-data, when s=1, and m=1 or m=2. In Hex.
Here, to create "C_A_D_of_TA" code-portion :
i will 1st create a DER file (C_A_D_of_TA.der), based on Level-3
dom1_tld_IA.crt file, and then in 2nd step i will append DER code
based on Level-2 My_i-CA.crt file, and then in 3rd step i will
append DER code based on Level-1 My_Root_CA.crt file. (Similar to
what we do for creating TLS chain cert for httpd server software) :
$ openssl x509 -in dom1_tld_IA.crt \
-outform der -out C_A_D_of_TA.der
$ openssl x509 -in My_i-CA.crt \
-outform der -out My_i-CA.der
$ cat My_i-CA.der >> C_A_D_of_TA.der
$ openssl x509 -in My_Root_CA.crt \
-outform der -out My_Root_CA.der
$ cat My_Root_CA.der >> C_A_D_of_TA.der
I (as Domain-owner) want my side NS/DNS-servers to serve FULL DER
TLS certs. Both TA/Root-CA and EE/Server-Cert.
Let us assume, i have such dns entries : Here 's1' is server
hostname. So is 's2'. Visitors & users will access 's1' srvr via
'www' srvc, and access 's2' srvr via 'm' service (service
sub-domain-name) normally. When/if 's1' srvr is down, then user
will goto 's2' srvr for 'www' srvc, and when 's2' srvr is down then
user will goto 's1' srvr for 'm' srvc:
% dom1.tld. 3600 IN SOA s1.dom1.tld. hostmaster.dom1.tld. 2013052910
18000 3600 864000 3600
% dom1.tld. 3000 IN NS s1.dom1.tld.
% dom1.tld. 3000 IN NS s2.dom1.tld.
% dom1.tld. 300 IN A IP.ADRS_S-1_IPv4
% dom1.tld. 300 IN A IP.ADRS_S-2_IPv4
% dom1.tld. 300 IN AAAA IP::ADRS_S-1_IPv6
% dom1.tld. 300 IN AAAA IP::ADRS_S-2_IPv6
% s1.dom1.tld. 900 IN A IP.ADRS_S-1_IPv4
% s2.dom1.tld. 900 IN A IP.ADRS_S-2_IPv4
% s1.dom1.tld. 900 IN AAAA IP::ADRS_S-1_IPv6
% s2.dom1.tld. 900 IN AAAA IP::ADRS_S-2_IPv6
% www.dom1.tld. 300 IN CNAME dom1.tld.
% m.dom1.tld. 300 IN CNAME dom1.tld.
% _http._tcp.dom1.tld. 3600 IN SRV 0 0 80 www.dom1.tld.
% _https._tcp.dom1.tld. 3600 IN SRV 0 0 443 www.dom1.tld.
% _http._tcp.www.dom1.tld. 3600 IN SRV 0 0 80 www.dom1.tld.
% _https._tcp.www.dom1.tld. 3600 IN SRV 0 0 443 www.dom1.tld.
% _http._tcp.m.dom1.tld. 3600 IN SRV 0 0 80 m.dom1.tld.
% _https._tcp.m.dom1.tld. 3600 IN SRV 0 0 443 m.dom1.tld.
% dom1.tld. 3600 IN MX 10 s1.dom1.tld.
% dom1.tld. 3600 IN MX 20 s2.dom1.tld.
% _smtp._tcp.dom1.tld. 3600 IN SRV 10 0 25 s1.dom1.tld.
% _smtp._tcp.dom1.tld. 3600 IN SRV 20 0 25 s2.dom1.tld.
% _smtp._tcp.s1.dom1.tld. 3600 IN SRV 10 0 25 s1.dom1.tld.
% _smtp._tcp.s1.dom1.tld. 3600 IN SRV 20 0 25 s2.dom1.tld.
% _smtp._tcp.s2.dom1.tld. 3600 IN SRV 10 0 25 s2.dom1.tld.
% _smtp._tcp.s2.dom1.tld. 3600 IN SRV 20 0 25 s1.dom1.tld.
% _submission._tcp.dom1.tld. 3600 IN SRV 10 0 587 s1.dom1.tld.
% _submission._tcp.dom1.tld. 3600 IN SRV 20 0 587 s2.dom1.tld.
% _submission._tcp.s1.dom1.tld. 3600 IN SRV 10 0 587 s1.dom1.tld.
% _submission._tcp.s1.dom1.tld. 3600 IN SRV 20 0 587 s2.dom1.tld.
% _submission._tcp.s2.dom1.tld. 3600 IN SRV 10 0 587 s2.dom1.tld.
% _submission._tcp.s2.dom1.tld. 3600 IN SRV 20 0 587 s1.dom1.tld.
% _imaps._tcp.dom1.tld. 3600 IN SRV 0 0 993 s1.dom1.tld.
% _imaps._tcp.dom1.tld. 3600 IN SRV 5 0 993 s2.dom1.tld.
% _imaps._tcp.s1.dom1.tld. 3600 IN SRV 0 0 993 s1.dom1.tld.
% _imaps._tcp.s1.dom1.tld. 3600 IN SRV 5 0 993 s2.dom1.tld.
% _imaps._tcp.s2.dom1.tld. 3600 IN SRV 0 0 993 s2.dom1.tld.
% _imaps._tcp.s2.dom1.tld. 3600 IN SRV 5 0 993 s1.dom1.tld.
% _pop3s._tcp.dom1.tld. 3600 IN SRV 0 0 995 s1.dom1.tld.
% _pop3s._tcp.dom1.tld. 3600 IN SRV 5 0 995 s2.dom1.tld.
% _pop3s._tcp.s1.dom1.tld. 3600 IN SRV 0 0 995 s1.dom1.tld.
% _pop3s._tcp.s1.dom1.tld. 3600 IN SRV 5 0 995 s2.dom1.tld.
% _pop3s._tcp.s2.dom1.tld. 3600 IN SRV 0 0 995 s2.dom1.tld.
% _pop3s._tcp.s2.dom1.tld. 3600 IN SRV 5 0 995 s1.dom1.tld.
I want, FUTURE FULL DANE & DNSSEC supported
web-browsers/HTTPS-clients (and httpd (HTTP, HTTPS) servers) to
pull/retrieve BOTH TA & EE type of certs from DNS, like : 1st
pull/retrieve FULL authentic EE/server-cert from TLSA dns ("1 S M" &
"3 S M" cases), and (in 2nd step), also pull/retrieve new
self-signed TA ("TLSA 2 S M"), or public CA ("TLSA 0 S M") from DNS
record (if it exist there and if required for TLS chain validation),
and after verifying TLSA EE cert and TLSA cert chain and
authenticity, then use EE/Server-Cert for creating authentic &
encrypted secured HTTPS connection.
I basically want both HTTPS-client and HTTPS-server, to retrieve,
domain-owner declared/published, both TA and EE full certificate
from DNS, and then after cert chain validation succeeds, use the EE
cert to create encrypted connection. Without depending on any .crt
files specified or loaded in/from server or client software.
Server-side software will only need cert's private_key file portion
for creating encrypted traffic.
So based on above expectation, i also want to add these:
% _443._tcp.www.dom1.tld. 180 IN TLSA 1 0 0 C_A_D_of_www_Srvr-Cert
% _443._tcp.m.dom1.tld. 180 IN TLSA 1 0 0 C_A_D_of_m_Srvr-Cert
Or, am i suppose to add these ?
% _443._tcp.www.dom1.tld. 180 IN TLSA 3 0 0 C_A_D_of_www_Srvr-Cert
% _443._tcp.m.dom1.tld. 180 IN TLSA 3 0 0 C_A_D_of_m_Srvr-Cert
I will create C_A_D_of_www_Srvr-Cert.der like this:
$ openssl x509 -in www_dom1_tld.crt \
-outform der \
-out C_A_D_of_www_Srvr-Cert.der
And for other certs:
$ openssl x509 -in m_dom1_tld.crt \
-outform der \
-out C_A_D_of_m_Srvr-Cert.der
$ openssl x509 -in s1_dom1_tld.crt \
-outform der \
-out C_A_D_of_s1_Srvr-Cert.der
$ openssl x509 -in s2_dom1_tld.crt \
-outform der \
-out C_A_D_of_s2_Srvr-Cert.der
So for my case, i will be adding both "TLSA 1 0 0" and "TLSA 2 0 0",
full certificates. To me, adding both TLSA "2 0 0" and "1 0 0" with
full certs, makes more sense, specially when domain-owner will be
using their own new self-signed/TA cert based solution. Then client
and server both can retrieve the TA and EE type cert using only one
channel, DNS-channel, port 53. I want to call it or treat it, as, a
Complete TLSA declaration, as it eliminates any chance of confusion,
and reduces TLS obtain & validation related steps, as it can easily
obtain all necessary full TLS certs from DNS records, authenticated
by DNSSEC.
I'm trying to say via DNS ... here (TLSA 1 0 0) is my server's
self-signed full EE/server-cert, and here (TLSA 2 0 0) is my own &
new self-signed full Root-CA/TA cert bundle, ... ( so, you(client)
must use these (TA & EE certs) to validate the cert chain. and then
on success, use the EE cert for creating HTTPS secured connection).
I want to support various & mixed channel based solutions, so i will
also do these : I will add both TLSA TA "2 0 0" and TLSA EE "1 0 0"
as mentioned in above. So that, clients & servers both side can
still obtain both TA & EE type of TLSA records via DNS channel (port
53). And i will also serve/share full TLS cert chain/bundle-file
from HTTPS-server (apache/httpd) service software. So that, clients
& servers both side can still obtain (1) server/EE-cert and rest of
the TLS cert chain's linked certs (if server/EE-cert requires), via
HTTPS channel (port 443) and/or using OCSP channel (port 80) for TLS
cert's PKIX validity).
I want, client & server software able to obtain & use entire EE cert
(from TLSA "1 S M" or TLSA "3 S M"), and i want them able to obtain
& use entire TA cert chain (from TLSA "2 S M" or TLSA "0 S M").
So for my case i will and want-to, use TLSA like this:
% _443._tcp.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA
% _443._tcp.s1.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA
% _443._tcp.s1.dom1.tld. 180 IN TLSA 1 0 0 C_A_D_of_s1_dom1_tld
% _443._tcp.s2.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA
% _443._tcp.s2.dom1.tld. 180 IN TLSA 1 0 0 C_A_D_of_s2_dom1_tld
% _443._tcp.www.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA
% _443._tcp.www.dom1.tld. 180 IN TLSA 1 0 0 C_A_D_of_www_dom1_tld
% _443._tcp.m.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA
% _443._tcp.m.dom1.tld. 180 IN TLSA 1 0 0 C_A_D_of_m_dom1_tld
% _25._tcp.s1.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA
% _25._tcp.s1.dom1.tld. 180 IN TLSA 1 0 0 C_A_D_of_s1_dom1_tld
% _993._tcp.s1.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA
% _993._tcp.s1.dom1.tld. 180 IN TLSA 1 0 0 C_A_D_of_s1_dom1_tld
% _995._tcp.s1.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA
% _995._tcp.s1.dom1.tld. 180 IN TLSA 1 0 0 C_A_D_of_s1_dom1_tld
% _587._tcp.s1.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA
% _587._tcp.s1.dom1.tld. 180 IN TLSA 1 0 0 C_A_D_of_s1_dom1_tld
% _25._tcp.s2.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA
% _25._tcp.s2.dom1.tld. 180 IN TLSA 1 0 0 C_A_D_of_s2_dom1_tld
% _993._tcp.s2.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA
% _993._tcp.s2.dom1.tld. 180 IN TLSA 1 0 0 C_A_D_of_s2_dom1_tld
% _995._tcp.s2.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA
% _995._tcp.s2.dom1.tld. 180 IN TLSA 1 0 0 C_A_D_of_s2_dom1_tld
% _587._tcp.s2.dom1.tld. 180 IN TLSA 2 0 0 C_A_D_of_TA
% _587._tcp.s2.dom1.tld. 180 IN TLSA 1 0 0 C_A_D_of_s2_dom1_tld
Does DANE currently allow TWO combined TLSA record usage ? i want to
use both TLSA TA ("TLSA 2 0 0") and TLSA EE ("TLSA 1 0 0")
dns-record, for verifying EE cert created under a self-signed new TA
cert, and force both client & server side to validate both type of
certs, and after validation succeeds, the EE cert will be used for
HTTPS encryption, by both client & server.
If such/above is not supported, then please add support for it.
Since i will not use partial cert portion or hash, in TLSA EE "1 S
M" or "3 S M" cases, so you may avoid referencing on that, and
please focus on full EE cert based practice/guidance/example. But
if (non-Full) partial cert is appropriate or adequate for TLSA TA "2
S M" or "0 S M" cases without invoking/using extra channel usage,
then pls do mention on that.
Please point out my errors, and help us/me/domain-owners with
better/improved configuration, thanks in advance.
-- Bright Star.
Jun 13, 2013.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
