This is the command ldns-dane that can be run in the OnWorks free hosting provider using one of our multiple free online workstations such as Ubuntu Online, Fedora Online, Windows online emulator or MAC OS online emulator
PROGRAM:
NAME
ldns-dane - verify or create TLS authentication with DANE (RFC6698)
SYNOPSIS
ldns-dane [OPTIONS] verify name port
ldns-dane [OPTIONS] -t tlsafile verify
ldns-dane [OPTIONS] name port create
[ Certificate-usage [ Selector [ Matching-type ] ] ]
ldns-dane -h
ldns-dane -v
DESCRIPTION
In the first form: A TLS connection to name:port is established. The TLSA resource
record(s) for name are used to authenticate the connection.
In the second form: The TLSA record(s) are read from tlsafile and used to authenticate the
TLS service they reference.
In the third form: A TLS connection to name:port is established and used to create the
TLSA resource record(s) that would authenticate the connection. The parameters for TLSA
rr creation are:
Certificate-usage:
0 CA constraint
1 Service certificate constraint
2 Trust anchor assertion
3 Domain-issued certificate (default)
Selector:
0 Full certificate (default)
1 SubjectPublicKeyInfo
Matching-type:
0 No hash used
1 SHA-256 (default)
2 SHA-512
In stead of numbers the first few letters of the value may be used. Except for the hash
algorithm name, where the full name must be specified.
OPTIONS
-4 TLS connect IPv4 only
-6 TLS connect IPv6 only
-a address
Don't try to resolve name, but connect to address instead.
This option may be given more than once.
-b print "name. TYPE52 \# size hexdata" form instead of TLSA presentation format.
-c certfile
Do not TLS connect to name:port, but authenticate (or make TLSA records) for the
certificate (chain) in certfile instead.
-d Assume DNSSEC validity even when the TLSA records were acquired insecure or were
bogus.
-f CAfile
Use CAfile to validate.
-h Print short usage help
-i Interact after connecting.
-k keyfile
Specify a file that contains a trusted DNSKEY or DS rr. Key(s) are used when
chasing signatures (i.e. -S is given).
This option may be given more than once.
Alternatively, if -k is not specified, and a default trust anchor
(/etc/unbound/root.key) exists and contains a valid DNSKEY or DS record, it will be
used as the trust anchor.
-n Do not verify server name in certificate.
-o offset
When creating a "Trust anchor assertion" TLSA resource record, select the offsetth
certificate offset from the end of the validation chain. 0 means the last
certificate, 1 the one but last, 2 the second but last, etc.
When offset is -1 (the default), the last certificate is used (like with 0) that
MUST be self-signed. This can help to make sure that the intended (self signed)
trust anchor is actually present in the server certificate chain (which is a DANE
requirement).
-p CApath
Use certificates in the CApath directory to validate.
-s When creating TLSA resource records with the "CA Constraint" and the "Service
Certificate Constraint" certificate usage, do not validate and assume PKIX is
valid.
For "CA Constraint" this means that verification should end with a self-signed
certificate.
-S Chase signature(s) to a known key.
Without this option, the local network is trusted to provide a DNSSEC resolver
(i.e. AD bit is checked).
-t tlsafile
Read TLSA record(s) from tlsafile. When name and port are also given, only TLSA
records that match the name, port and transport are used. Otherwise the owner name
of the TLSA record(s) will be used to determine name, port and transport.
-T Return exit status 2 for PKIX validated connections without (secure) TLSA
records(s)
-u Use UDP transport instead of TCP.
-v Show version and exit.
Use ldns-dane online using onworks.net services
