From mboxrd@z Thu Jan  1 00:00:00 1970
From: Michael Tremer <michael.tremer@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: [Fwd: Re: request for info: unbound via https / tls]
Date: Tue, 11 Dec 2018 19:22:42 +0000
Message-ID: <BED9DA78-3B6B-4EE6-849B-6F5BF700689D@ipfire.org>
In-Reply-To: <9b77b351ee0c81390c9814acd845d231dfb2ab94.camel@ipfire.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============2362531446070433121=="
List-Id: <development.lists.ipfire.org>

--===============2362531446070433121==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Hey,

Could you try that again? I removed the OCSP must-staple flag from the certif=
icate.

-Michael

> On 10 Dec 2018, at 14:37, ummeegge <ummeegge(a)ipfire.org> wrote:
>=20
> Great that you looked over it, have tested it again and the kdig report
> differs which looks now like this:
>=20
> ;; DEBUG: Querying for owner(google.com.), class(1), type(1),
> server(81.3.27.54), port(853), protocol(TCP)
> ;; DEBUG: TLS, imported 128 certificates from '/etc/ssl/certs/ca-
> bundle.crt'
> ;; DEBUG: TLS, received certificate hierarchy:
> ;; DEBUG:  #1, CN=3Drec1.dns.lightningwirelabs.com
> ;; DEBUG:      SHA-256 PIN:
> ZayzRhKLRWLL7v9QC0uEJEMomE572oNUuF4ocAxDQ7E=3D
> ;; DEBUG:  #2, C=3DUS,O=3DLet's Encrypt,CN=3DLet's Encrypt Authority X3
> ;; DEBUG:      SHA-256 PIN:
> YLh1dUR9y6Kja30RrAn7JKnbQG/uEtLMkBgFF2Fuihg=3D
> ;; DEBUG: TLS, skipping certificate PIN check
> ;; DEBUG: TLS, The certificate is NOT trusted. The certificate requires
> the server to include an OCSP status in its response, but the OCSP
> status is missing.=20
> ;; WARNING: TLS, handshake failed (Error in the certificate.)
> ;; WARNING: failed to query server 81.3.27.54(a)853(TCP)
>=20
> Exit status: 0
>=20
> May this is helpful for you.
>=20
> Best,
>=20
> Erik
>=20
> Am Montag, den 10.12.2018, 13:26 +0000 schrieb Michael Tremer:
>> Hey,
>>=20
>> Thanks for reporting.
>>=20
>>> On 10 Dec 2018, at 12:32, ummeegge <ummeegge(a)ipfire.org> wrote:
>>>=20
>>> A question,
>>> what happens with DoT on Lightningwirelabs -->
>>>=20
> https://www.lightningwirelabs.com/2018/05/03/dns-over-tls-now-available-on-=
our-resolvers
>>> ?
>>> I get there an
>>>=20
>>> $ kdig -d @81.3.27.54 +tls-ca=3D/etc/ssl/certs/ca-bundle.crt +tls-
>>> host=3D"ns1.lightningwirelabs.com" google.com;
>>> ;; DEBUG: Querying for owner(google.com.), class(1), type(1),
>>> server(81.3.27.54), port(853), protocol(TCP)
>>> ;; DEBUG: TLS, imported 128 certificates from '/etc/ssl/certs/ca-
>>> bundle.crt'
>>> ;; WARNING: can't connect to 81.3.27.54(a)853(TCP)
>>> ;; WARNING: failed to query server 81.3.27.54(a)853(TCP)
>>=20
>> I recently made a change which caused that unbound didn=E2=80=99t listen on
>> the TLS port any more.
>>=20
>> I fixed that now.
>>=20
>> The correct host name for that server is
>> rec1.dns.lightningwirelabs.com.
>>=20
>> -Michael
>>=20
>>> .
>>>=20
>>> Best,
>>>=20
>>> Erik
>>>=20
>>=20
>>=20
>=20


--===============2362531446070433121==--