Menu
What's new
By:
Filters Better Search

Stubby-Installer-Asuswrt-Merlin

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

M@rco said:
These iptables to redirect everything to stubby are in place:

Code: 
# Force Client DNS requests to use Stubby
iptables -t nat -A PREROUTING -i br0 -p udp --dport 53 -j DNAT --to "$(nvram get lan_ipaddr)"
iptables -t nat -A PREROUTING -i br0 -p tcp --dport 53 -j DNAT --to "$(nvram get lan_ipaddr)"

However, running with @127.0.0.1 indeed fails:

Code: 
# dig asuswrt.lostrealm.ca @127.0.0.1 +dnssec +multi

; <<>> DiG 9.11.3 <<>> asuswrt.lostrealm.ca @127.0.0.1 +dnssec +multi
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1950
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1452
;; QUESTION SECTION:
;asuswrt.lostrealm.ca.  IN A

;; ANSWER SECTION:
asuswrt.lostrealm.ca.   164 IN A 72.55.186.51
asuswrt.lostrealm.ca.   164 IN RRSIG A 13 3 300 (
                                20181023110146 20181021090146 35273 lostrealm.ca.
                                4d0TFNjIqkyCnOIZhc1sis9ElTT50mziKqFKZ1WNa1xm
                                wpEgJs+BrYltFNVvxWzONpydai5DqbQex758EHPylw== )

;; Query time: 13 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Oct 22 10:04:02 UTC 2018
;; MSG SIZE  rcvd: 213

Do you have a solution @DonnyJohnny?
Click to expand...
Understand about the iptables divert but coz the dig command specifically asking it to resolve via 1.1.1.1
Anyway currently only way is use firmware dnssec validation with strict unsigned validation set to NO.

Technically, we should use strict unsigned validation to YES to maximum the objective of DNSSEC, as by setting strict validation to no mean unsigned dnssec will still still pass thru as insecure but valid.

I am wondering if this is Cloudflare specific problem with dnssec validation.
Maybe u can just try do some testing with other resolvers with strict validation set to YES
https://dnsprivacy.org/wiki/plugins/servlet/mobile?contentId=1277971#content/view/1277971
 
(1) I did another test. I set dnssec_return_status: GETDNS_EXTENSION_TRUE in stubby.yml. I changed appdata_dir to point to the backup location containing the root key files. I bounced stubby. https://1.1.1.1/help fails the test. I do pass the DNSSEC tests on http://dnssec.vs.uni-due.de/ and https://rootcanary.org/test.html.

No "ad" flag appears when I do a drill -D asuswrt.lostrealm.ca @127.0.0.1

(2)I then commented out dnssec_return_status: GETDNS_EXTENSION_TRUE and kept the reference to the appdata_dir. https://1.1.1.1/help passes the test. I also pass the DNSSEC tests on http://dnssec.vs.uni-due.de/ and https://rootcanary.org/test.html.

No "ad" flag appears when I do a drill -D asuswrt.lostrealm.ca @127.0.0.1

(3) dnssec_return_status: GETDNS_EXTENSION_TRUE in no longer commented out. I changed the reference to the appdata_dir to /opt/var/cache/stubby (no root anchor files). https://1.1.1.1/help passes the test. I fail the DNSSEC tests on http://dnssec.vs.uni-due.de/ and https://rootcanary.org/test.html.

No "ad" flag appears when I do a drill -D asuswrt.lostrealm.ca @127.0.0.


 
Last edited:
Congrats @Xentrk for your release.
This sure will make it into amtm as soon as the RT-AC86U problem is solved. I will also rejoin the testing once you have figured out what's causing the stoppages.
 
Xentrk said:
(1) I did another test. I set dnssec_return_status: GETDNS_EXTENSION_TRUE in stubby.yml. I changed appdata_dir to point to the backup location containing the root key files. I bounced stubby. https://1.1.1.1/help fails the test. I do pass the DNSSEC tests on http://dnssec.vs.uni-due.de/ and https://rootcanary.org/test.html.

No "ad" flag appears when I do a drill -D asuswrt.lostrealm.ca @127.0.0.1

(2)I then commented out dnssec_return_status: GETDNS_EXTENSION_TRUE and kept the reference to the appdata_dir. https://1.1.1.1/help passes the test. I also pass the DNSSEC tests on http://dnssec.vs.uni-due.de/ and https://rootcanary.org/test.html.

No "ad" flag appears when I do a drill -D asuswrt.lostrealm.ca @127.0.0.1

(3) dnssec_return_status: GETDNS_EXTENSION_TRUE in no longer commented out. I changed the reference to the appdata_dir to /opt/var/cache/stubby (no root anchor files). https://1.1.1.1/help passes the test. I fail the DNSSEC tests on http://dnssec.vs.uni-due.de/ and https://rootcanary.org/test.html.

No "ad" flag appears when I do a drill -D asuswrt.lostrealm.ca @127.0.0.
Click to expand...
I have tested securedns.eu
Using strict dnssec validation = YES.
The result is good with AD flag.
It seems like both Quad9 and Cloudflare has some misconfigurations causing them not about to have the strict dnssec validation.
 
I had to reinstall Entware and Stubby after a thumb drive failure Saturday night. As of now I'm not running the changes that were made just before the release other than my modifications.
I had noticed that the root.key seemed to update frequently when dnssec_return_status: GETDNS_EXTENSION_TRUE is enabled so I created /jffs/cache/stubby and set appdata_dir: "/jffs/cache/stubby" I seem to remember something about minimizing writes to thumb drives. May be just "old guy" thinking... Reads and writes are also faster to /jffs.

Ah, I should also add that I've set my NTP Server to an IP address (as I am close to NIST I am using 129.6.15.28). In testing we discovered the router would not get a time sync on reboot with dnssec_return_status: GETDNS_EXTENSION_TRUE enabled. Using an IP is one workaround. However, you should use a time server IP that has a high probability of being up when you reboot your router! You can get an IP of a time server with a ping or nslookup but keep in mind that services like ntp;pool.org rotate the load among many servers so the IP's used change.

Here is my stubby.yml:
Code: 
# stubby.yml configuration file created by Xentrk
# version 1.0.0
tls_ca_file: "/opt/etc/ssl/certs/ca-certificates.crt"
resolution_type: GETDNS_RESOLUTION_STUB
dns_transport_list:
  - GETDNS_TRANSPORT_TLS
tls_authentication: GETDNS_AUTHENTICATION_REQUIRED
dnssec_return_status: GETDNS_EXTENSION_TRUE
tls_query_padding_blocksize: 128
edns_client_subnet_private : 1
round_robin_upstreams: 0
idle_timeout: 2000
tls_connection_retries: 5
tls_backoff_time: 900
timeout: 2000
appdata_dir: "/jffs/cache/stubby"
listen_addresses:
  - 127.0.0.1@5453

upstream_recursive_servers:
# Cloudflare Primary IPv4
  - address_data: 1.1.1.1
    tls_auth_name: "cloudflare-dns.com"
# Cloudflare Secondary IPv4
  - address_data: 1.0.0.1
    tls_auth_name: "cloudflare-dns.com"
 
Last edited:
bbunge said:
I had to reinstall Entware and Stubby after a thumb drive failure Saturday night. As of now I'm not running the changes that were made just before the release other than my modifications.
I had noticed that the root.key seemed to update frequently when dnssec_return_status: GETDNS_EXTENSION_TRUE is enabled so I created /jffs/cache/stubby and set appdata_dir: "/jffs/cache/stubby" I seem to remember something about minimizing writes to thumb drives. May be just "old guy" thinking... Reads and writes are also faster to /jffs.
Click to expand...
Probably best to change it back to use the USB drive. Per the Wiki, the recommendation is to use the USB for frequent read and writes to avoid wearing out /jffs partition.

I do not recommend doing frequent writes to this area, as it will prematurely wear out the flash chip. This is a good place to put files that are written once like scripts or kernel modules, or that rarely get written to. Do not put files that get constantly written to (such as high activity logfiles) - store these on a USB disk instead. Replacing a worn out USB flash disk is much cheaper than replacing the whole router if flash sectors get worn out - they have a limited number of write cycles.
Click to expand...
 
I think the issue with Cloudflare is, or might be, related to getdns currently not yet being build against openssl 1.1.1. See this github issue: https://github.com/getdnsapi/stubby/issues/132 (near the end, posts from the last few weeks). A new version is likely to be released this week. However, openssl in entware is at 1.0.2 and it might take some time to get the latest release of stubby in entware repositories as well.
 
Xentrk said:
Probably best to change it back to use the USB drive. Per the Wiki, the recommendation is to use the USB for frequent read and writes to avoid wearing out /jffs partition.
Click to expand...
Believe that rational has been changed for modern routers. If it were true why would Asus and Merlin use /jffs for logs , lists, and etc. ?
 
bbunge said:
Believe that rational has been changed for modern routers. If it were true why would Asus and Merlin use /jffs for logs , lists, and etc. ?
Click to expand...
I think it's mainly syslog. Probably mostly because Asuswrt-Merlin needs to be able to run without a USB drive inserted. As /jffs is non-replaceable and a usb drive is, I prefer a usb drive as well.
 
What's currently working for me is setting Enable DNSSEC support to Yes and setting DNSSEC: strict unsigned validation to No. This way CF DoT validation works as well as DNSSEC validation directly on the router using dig:

Code: 
# dig asuswrt.lostrealm.ca +dnssec +multi

; <<>> DiG 9.11.3 <<>> asuswrt.lostrealm.ca +dnssec +multi
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13794
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1452
;; QUESTION SECTION:
;asuswrt.lostrealm.ca.  IN A

;; ANSWER SECTION:
asuswrt.lostrealm.ca.   300 IN A 72.55.186.51
asuswrt.lostrealm.ca.   300 IN RRSIG A 13 3 300 (
                                20181023150920 20181021130920 35273 lostrealm.ca.
                                E5wpzoQIAjT/YaxfYy4Tqm96BzArop95LQirTyh4yplQ
                                YFY2JeLL3qpu5bmUXCprPxQqK30lfsAOOmPpzn9qLw== )

;; Query time: 136 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Oct 22 14:09:20 UTC 2018
;; MSG SIZE  rcvd: 213

I will try other DNS servers later today, as others are using the network currently.
 
M@rco said:
What's currently working for me is setting Enable DNSSEC support to Yes and setting DNSSEC: strict unsigned validation to No. This way CF DoT validation works as well as DNSSEC validation directly on the router using dig:
Click to expand...

But it means that anyone can forge a DNS reply and simply not sign it, and your router will blindly accept it, making DNSSEC completely useless. If you can't use DNSSEC with strict unsigned validation, then you should not be using DNSSEC at all.
 
RMerlin said:
But it means that anyone can forge a DNS reply and simply not sign it, and your router will blindly accept it, making DNSSEC completely useless. If you can't use DNSSEC with strict unsigned validation, then you should not be using DNSSEC at all.
Click to expand...

I'm aware of that, thanks. Any suggestions why enabling DNSSEC (with or without strict unsigned validation) seems to break DoT? As soon as DNSSEC is enabled, https://1.1.1.1/help fails to validate being connected to 1.1.1.1 and fails in validating DoT.
 
M@rco said:
I'm aware of that, thanks. Any suggestions why enabling DNSSEC (with or without strict unsigned validation) seems to break DoT? As soon as DNSSEC is enabled, https://1.1.1.1/help fails to validate being connected to 1.1.1.1 and fails in validating DoT.
Click to expand...
I disabled the line the .yml file and then enabled dnssec. Works like a charm. http://1.1.1.1/help correctly identifies my dns set to be 1.1.1.1 and 1.0.0.1 as well it says it's in YVR which is BC Canada and it says cloudflare number.

Connected to 1.1.1.1 No
Using DNS over HTTPS (DoH) No
Using DNS over TLS (DoT) No
AS Name Cloudflare
AS Number 13335
Cloudflare Data Center YVR
Connectivity to Resolver IP Addresses
1.1.1.1 Yes
1.0.0.1 Yes
2606:4700:4700::1111 No
2606:4700:4700::1001 No
 
As far as breaking DoT I say not. I have re-ran that kdig command from cloudflare and it works every time. With dnssec enabled in the webui.
 
M@rco said:
I'm aware of that, thanks. Any suggestions why enabling DNSSEC (with or without strict unsigned validation) seems to break DoT? As soon as DNSSEC is enabled, https://1.1.1.1/help fails to validate being connected to 1.1.1.1 and fails in validating DoT.
Click to expand...

I have no idea how that test works or what it's actually testing.
 
Hello,

Everything seems to work properly on my AC3100 except this error

/tmp/home/root# echo | openssl s_client -verify on -CApath /opt/etc/ssl/certs -connect 1.1.1.1:853
verify depth is 0
CONNECTED(00000003)
depth=1 C = US, O = DigiCert Inc, CN = DigiCert ECC Secure Server CA
verify error:num=20:unable to get local issuer certificate
717190064:error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed:s3_clnt.c:1269:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 2074 bytes and written 7 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : 0000
Session-ID: 6FF18E17D5A9FBFBC9BF3A747C41CBCA6CD5523D54B012683D913EDC3144BA0E
Session-ID-ctx:
Master-Key:
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1540308994
Timeout : 300 (sec)
Verify return code: 0 (ok)
 
Sebastien Bougie said:
Hello,

Everything seems to work properly on my AC3100 except this error

/tmp/home/root# echo | openssl s_client -verify on -CApath /opt/etc/ssl/certs -connect 1.1.1.1:853
verify depth is 0
CONNECTED(00000003)
depth=1 C = US, O = DigiCert Inc, CN = DigiCert ECC Secure Server CA
verify error:num=20:unable to get local issuer certificate
717190064:error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed:s3_clnt.c:1269:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 2074 bytes and written 7 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : 0000
Session-ID: 6FF18E17D5A9FBFBC9BF3A747C41CBCA6CD5523D54B012683D913EDC3144BA0E
Session-ID-ctx:
Master-Key:
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1540308994
Timeout : 300 (sec)
Verify return code: 0 (ok)
Click to expand...

That's caused by a last-minute change. Earlier in testing we used the entware package ca-certificates, but @Xentrk is now using the certificates which come with the firmware. If you want to run the check, install ca-certificates from entware:

Code: 
opkg update && opkg install ca-certificates

It should return something like this:

Code: 
# echo | openssl s_client -verify on -CApath /opt/etc/ssl/certs -connect 1.1.1.1:853
verify depth is 0
CONNECTED(00000003)
depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA
verify return:1
depth=1 C = US, O = DigiCert Inc, CN = DigiCert ECC Secure Server CA
verify return:1
depth=0 C = US, ST = CA, L = San Francisco, O = "Cloudflare, Inc.", CN = *.cloudflare-dns.com
verify return:1
---
Certificate chain
 0 s:/C=US/ST=CA/L=San Francisco/O=Cloudflare, Inc./CN=*.cloudflare-dns.com
   i:/C=US/O=DigiCert Inc/CN=DigiCert ECC Secure Server CA
 1 s:/C=US/O=DigiCert Inc/CN=DigiCert ECC Secure Server CA
   i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA
---
Server certificate
-----BEGIN CERTIFICATE-----
MIID9DCCA3qgAwIBAgIQBWzetBRl/ycHFsBukRYuGTAKBggqhkjOPQQDAjBMMQsw
CQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMSYwJAYDVQQDEx1EaWdp
Q2VydCBFQ0MgU2VjdXJlIFNlcnZlciBDQTAeFw0xODAzMzAwMDAwMDBaFw0yMDAz
MjUxMjAwMDBaMGwxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDQTEWMBQGA1UEBxMN
U2FuIEZyYW5jaXNjbzEZMBcGA1UEChMQQ2xvdWRmbGFyZSwgSW5jLjEdMBsGA1UE
AwwUKi5jbG91ZGZsYXJlLWRucy5jb20wWTATBgcqhkjOPQIBBggqhkjOPQMBBwNC
AASyRQsxrFBjziHmfDQjGsXBU0WWl3oxh7vg6h2V9f8lBMp18PY/td9R6VvJPa20
AwVzIJI+dL6OSxviaIZEbmK7o4ICHDCCAhgwHwYDVR0jBBgwFoAUo53mH/naOU/A
buiRy5Wl2jHiCp8wHQYDVR0OBBYEFN+XTeVDs7BBp0LykM+Jf64SV4ThMGMGA1Ud
EQRcMFqCFCouY2xvdWRmbGFyZS1kbnMuY29thwQBAQEBhwQBAAABghJjbG91ZGZs
YXJlLWRucy5jb22HECYGRwBHAAAAAAAAAAAAERGHECYGRwBHAAAAAAAAAAAAEAEw
DgYDVR0PAQH/BAQDAgeAMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjBp
BgNVHR8EYjBgMC6gLKAqhihodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vc3NjYS1l
Y2MtZzEuY3JsMC6gLKAqhihodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vc3NjYS1l
Y2MtZzEuY3JsMEwGA1UdIARFMEMwNwYJYIZIAYb9bAEBMCowKAYIKwYBBQUHAgEW
HGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DUFMwCAYGZ4EMAQICMHsGCCsGAQUF
BwEBBG8wbTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMEUG
CCsGAQUFBzAChjlodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNlcnRF
Q0NTZWN1cmVTZXJ2ZXJDQS5jcnQwDAYDVR0TAQH/BAIwADAKBggqhkjOPQQDAgNo
ADBlAjEAjoyy2Ogh1i1/Kh9+psMc1OChlQIvQF6AkojZS8yliar6m8q5nqC3qe0h
HR0fExwLAjAueWRnHX4QJ9loqMhsPk3NB0Cs0mStsNDNG6/DpCYw7XmjoG3y1LS7
ZkZZmqNn2Q8=
-----END CERTIFICATE-----
subject=/C=US/ST=CA/L=San Francisco/O=Cloudflare, Inc./CN=*.cloudflare-dns.com
issuer=/C=US/O=DigiCert Inc/CN=DigiCert ECC Secure Server CA
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 2660 bytes and written 421 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-ECDSA-AES256-GCM-SHA384
Server public key is 256 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-ECDSA-AES256-GCM-SHA384
    Session-ID: 439723CFC92EE025EBAAA050CB1F7369CA6A96E0D424D4BFD261F3DA0FD508B7
    Session-ID-ctx:
    Master-Key: 5C9326448166902D380EA53AF30A99C14C87F18D95545069A3DF2DA07D70956DB0BCCC84C471A8C5CBB3C826FA9BF79A
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 21600 (seconds)
    TLS session ticket:
    0000 - 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00   ................
    0010 - 67 77 68 4a 60 f0 26 8c-b8 7b e7 b8 45 87 59 75   gwhJ`.&..{..E.Yu
    0020 - 01 30 11 6a 11 19 98 f3-ae cb 8a 15 fa 1c cb b4   .0.j............
    0030 - 46 4e a8 2d dd 76 ee 3c-25 b4 b5 a9 81 11 a2 ab   FN.-.v.<%.......
    0040 - da e0 a4 03 2c 00 f7 a9-f3 da 18 df e5 73 2b 8d   ....,........s+.
    0050 - fe 7b e0 ab fe 45 c0 08-2d 4a f4 bb b5 50 91 57   .{...E..-J...P.W
    0060 - 01 23 96 bc 5e 53 3f fb-1a 6f 47 39 f9 72 bc 02   .#..^S?..oG9.r..
    0070 - 90 e2 03 40 61 29 da d4-11 12 ce 83 30 7c 5b ae   ...@a)......0|[.
    0080 - 96 f9 36 66 e8 6a 1b 3e-59 f0 fe c2 55 5e 6b ca   ..6f.j.>Y...U^k.
    0090 - 7e b9 62 bd bb 80 cc 8c-49 ba 0e be 1c 1e 5b 2d   ~.b.....I.....[-
    00a0 - 1c 3d d1 91 7f 28 bb 7b-68 b4 ab 30 33 04 dc 18   .=...(.{h..03...
    00b0 - 02 16 3c ed cc 49 a1 c4-01 71 70 13 69 44 c3 a3   ..<..I...qp.iD..
    00c0 - cb 9f 25 b3 5f 18 d7 fe-f3 d9 3d 75 18 3f 76 db   ..%._.....=u.?v.
    00d0 - 19 3a 96 de 0e f9 27 6d-6b c2 19 05 2e 72 0e 22   .:....'mk....r."
    00e0 - 64 4b 4a bb ae 66 10 4a-5a ab 54 20 2c e6 2d 2d   dKJ..f.JZ.T ,.--
    00f0 - ae eb de 99 a1 2c 8d 87-d7 8c b0 31 66 e6 ab 2d   .....,.....1f..-
    0100 - 26 89 c7 ce 88 21 77 4e-d7 28 d2 da 62 91 bb b2   &....!wN.(..b...
    0110 - 89 cb 6a 6d 4f 3b 3e 31-d9 7e 83 49 3f 51 b8 6c   ..jmO;>1.~.I?Q.l
    0120 - 77 a6 14 18 06 b4 0c 0e-df 73 05 52 f8 1d 86 9d   w........s.R....
    0130 - 17 03 bb 51 53 39 21 b3-77 bc b7 00 c6 3a b6 50   ...QS9!.w....:.P
    0140 - 63 8c 6e 95 b3 34 fd 12-08 d3 ac c4 e4 99 6c bd   c.n..4........l.
    0150 - 2b 52 01 2f cb 3c ff 08-23 59 c8 2a 43 5d e1 27   +R./.<..#Y.*C].'
    0160 - 4c 39 c9 96 8e 96                                 L9....

    Start Time: 1540314870
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---
DONE

You can remove ca-certificates afterwards, it is currently not needed to run stubby. To remove, execute:

Code: 
opkg remove ca-certificates

@Xentrk: This should probably be removed from the README.md, as it appears not to work with the certificate stored in /rom/etc/ssl/certs.
 
Last edited by a moderator:
M@rco said:
That's caused by a last-minute change. Earlier in testing we used the entware package ca-certificates, but @Xentrk is now using the certificates which come with the firmware. If you want to run the check, install ca-certificates from entware:

Code: 
opkg update && opkg install ca-certificates

It should return something like this:

Code: 
# echo | openssl s_client -verify on -CApath /opt/etc/ssl/certs -connect 1.1.1.1:853
verify depth is 0
CONNECTED(00000003)
depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA
verify return:1
depth=1 C = US, O = DigiCert Inc, CN = DigiCert ECC Secure Server CA
verify return:1
depth=0 C = US, ST = CA, L = San Francisco, O = "Cloudflare, Inc.", CN = *.cloudflare-dns.com
verify return:1
---
Certificate chain
 0 s:/C=US/ST=CA/L=San Francisco/O=Cloudflare, Inc./CN=*.cloudflare-dns.com
   i:/C=US/O=DigiCert Inc/CN=DigiCert ECC Secure Server CA
 1 s:/C=US/O=DigiCert Inc/CN=DigiCert ECC Secure Server CA
   i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA
---
Server certificate
-----BEGIN CERTIFICATE-----
MIID9DCCA3qgAwIBAgIQBWzetBRl/ycHFsBukRYuGTAKBggqhkjOPQQDAjBMMQsw
CQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMSYwJAYDVQQDEx1EaWdp
Q2VydCBFQ0MgU2VjdXJlIFNlcnZlciBDQTAeFw0xODAzMzAwMDAwMDBaFw0yMDAz
MjUxMjAwMDBaMGwxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDQTEWMBQGA1UEBxMN
U2FuIEZyYW5jaXNjbzEZMBcGA1UEChMQQ2xvdWRmbGFyZSwgSW5jLjEdMBsGA1UE
AwwUKi5jbG91ZGZsYXJlLWRucy5jb20wWTATBgcqhkjOPQIBBggqhkjOPQMBBwNC
AASyRQsxrFBjziHmfDQjGsXBU0WWl3oxh7vg6h2V9f8lBMp18PY/td9R6VvJPa20
AwVzIJI+dL6OSxviaIZEbmK7o4ICHDCCAhgwHwYDVR0jBBgwFoAUo53mH/naOU/A
buiRy5Wl2jHiCp8wHQYDVR0OBBYEFN+XTeVDs7BBp0LykM+Jf64SV4ThMGMGA1Ud
EQRcMFqCFCouY2xvdWRmbGFyZS1kbnMuY29thwQBAQEBhwQBAAABghJjbG91ZGZs
YXJlLWRucy5jb22HECYGRwBHAAAAAAAAAAAAERGHECYGRwBHAAAAAAAAAAAAEAEw
DgYDVR0PAQH/BAQDAgeAMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjBp
BgNVHR8EYjBgMC6gLKAqhihodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vc3NjYS1l
Y2MtZzEuY3JsMC6gLKAqhihodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vc3NjYS1l
Y2MtZzEuY3JsMEwGA1UdIARFMEMwNwYJYIZIAYb9bAEBMCowKAYIKwYBBQUHAgEW
HGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DUFMwCAYGZ4EMAQICMHsGCCsGAQUF
BwEBBG8wbTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMEUG
CCsGAQUFBzAChjlodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNlcnRF
Q0NTZWN1cmVTZXJ2ZXJDQS5jcnQwDAYDVR0TAQH/BAIwADAKBggqhkjOPQQDAgNo
ADBlAjEAjoyy2Ogh1i1/Kh9+psMc1OChlQIvQF6AkojZS8yliar6m8q5nqC3qe0h
HR0fExwLAjAueWRnHX4QJ9loqMhsPk3NB0Cs0mStsNDNG6/DpCYw7XmjoG3y1LS7
ZkZZmqNn2Q8=
-----END CERTIFICATE-----
subject=/C=US/ST=CA/L=San Francisco/O=Cloudflare, Inc./CN=*.cloudflare-dns.com
issuer=/C=US/O=DigiCert Inc/CN=DigiCert ECC Secure Server CA
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 2660 bytes and written 421 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-ECDSA-AES256-GCM-SHA384
Server public key is 256 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-ECDSA-AES256-GCM-SHA384
    Session-ID: 439723CFC92EE025EBAAA050CB1F7369CA6A96E0D424D4BFD261F3DA0FD508B7
    Session-ID-ctx:
    Master-Key: 5C9326448166902D380EA53AF30A99C14C87F18D95545069A3DF2DA07D70956DB0BCCC84C471A8C5CBB3C826FA9BF79A
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 21600 (seconds)
    TLS session ticket:
    0000 - 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00   ................
    0010 - 67 77 68 4a 60 f0 26 8c-b8 7b e7 b8 45 87 59 75   gwhJ`.&..{..E.Yu
    0020 - 01 30 11 6a 11 19 98 f3-ae cb 8a 15 fa 1c cb b4   .0.j............
    0030 - 46 4e a8 2d dd 76 ee 3c-25 b4 b5 a9 81 11 a2 ab   FN.-.v.<%.......
    0040 - da e0 a4 03 2c 00 f7 a9-f3 da 18 df e5 73 2b 8d   ....,........s+.
    0050 - fe 7b e0 ab fe 45 c0 08-2d 4a f4 bb b5 50 91 57   .{...E..-J...P.W
    0060 - 01 23 96 bc 5e 53 3f fb-1a 6f 47 39 f9 72 bc 02   .#..^S?..oG9.r..
    0070 - 90 e2 03 40 61 29 da d4-11 12 ce 83 30 7c 5b ae   ...@a)......0|[.
    0080 - 96 f9 36 66 e8 6a 1b 3e-59 f0 fe c2 55 5e 6b ca   ..6f.j.>Y...U^k.
    0090 - 7e b9 62 bd bb 80 cc 8c-49 ba 0e be 1c 1e 5b 2d   ~.b.....I.....[-
    00a0 - 1c 3d d1 91 7f 28 bb 7b-68 b4 ab 30 33 04 dc 18   .=...(.{h..03...
    00b0 - 02 16 3c ed cc 49 a1 c4-01 71 70 13 69 44 c3 a3   ..<..I...qp.iD..
    00c0 - cb 9f 25 b3 5f 18 d7 fe-f3 d9 3d 75 18 3f 76 db   ..%._.....=u.?v.
    00d0 - 19 3a 96 de 0e f9 27 6d-6b c2 19 05 2e 72 0e 22   .:....'mk....r."
    00e0 - 64 4b 4a bb ae 66 10 4a-5a ab 54 20 2c e6 2d 2d   dKJ..f.JZ.T ,.--
    00f0 - ae eb de 99 a1 2c 8d 87-d7 8c b0 31 66 e6 ab 2d   .....,.....1f..-
    0100 - 26 89 c7 ce 88 21 77 4e-d7 28 d2 da 62 91 bb b2   &....!wN.(..b...
    0110 - 89 cb 6a 6d 4f 3b 3e 31-d9 7e 83 49 3f 51 b8 6c   ..jmO;>1.~.I?Q.l
    0120 - 77 a6 14 18 06 b4 0c 0e-df 73 05 52 f8 1d 86 9d   w........s.R....
    0130 - 17 03 bb 51 53 39 21 b3-77 bc b7 00 c6 3a b6 50   ...QS9!.w....:.P
    0140 - 63 8c 6e 95 b3 34 fd 12-08 d3 ac c4 e4 99 6c bd   c.n..4........l.
    0150 - 2b 52 01 2f cb 3c ff 08-23 59 c8 2a 43 5d e1 27   +R./.<..#Y.*C].'
    0160 - 4c 39 c9 96 8e 96                                 L9....

    Start Time: 1540314870
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---
DONE

You can remove ca-certificates afterwards, it is currently not needed to run stubby. To remove, execute:

Code: 
opkg remove ca-certificates

@Xentrk: This should probably be removed from the README.md, as it appears not to work with the certificate stored in /rom/etc/ssl/certs.
Click to expand...
@M@rco and @Sebastien Bougie
README.md updated to use CA cert path in rom. It worked for me:
Code: 
echo | openssl s_client -verify on -CApath /rom/etc/ssl/certs -connect 1.1.1.1:853

Let me know your results.
 
Last edited:
Xentrk said:
@M@rco and @Sebastien Bougie
README.md updated to use CA cert path in rom. It worked for me:

echo | openssl s_client -verify on -CApath /rom/etc/ssl/certs -connect 1.1.1.1:853

Let me know your results.
Click to expand...

Hello,

This is what i'm getting

:/tmp/home/root# echo | openssl s_client -verify on -CApat
h /rom/etc/ssl/certs -connect 1.1.1.1:853
verify depth is 0
CONNECTED(00000003)
depth=1 C = US, O = DigiCert Inc, CN = DigiCert ECC Secure Server CA
verify error:num=20:unable to get local issuer certificate
717304752:error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed:s3_clnt.c:1269:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 2074 bytes and written 7 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : 0000
Session-ID: 06FD8C929548B1245AD0F306A14BE174E12E1E6DE2E6CAA2149AEA2B3BCAF2D1
Session-ID-ctx:
Master-Key:
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1540378998
Timeout : 300 (sec)
Verify return code: 0 (ok)
 
Sebastien Bougie said:
Hello,

This is what i'm getting

:/tmp/home/root# echo | openssl s_client -verify on -CApat
h /rom/etc/ssl/certs -connect 1.1.1.1:853
verify depth is 0
CONNECTED(00000003)
depth=1 C = US, O = DigiCert Inc, CN = DigiCert ECC Secure Server CA
verify error:num=20:unable to get local issuer certificate
717304752:error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed:s3_clnt.c:1269:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 2074 bytes and written 7 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : 0000
Session-ID: 06FD8C929548B1245AD0F306A14BE174E12E1E6DE2E6CAA2149AEA2B3BCAF2D1
Session-ID-ctx:
Master-Key:
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1540378998
Timeout : 300 (sec)
Verify return code: 0 (ok)
Click to expand...
Please check the directory /rom/etc/ssl/certs/ and see if you have a file called ca-certificates.crt in the folder.

If still a problem, try installing ca-certificates and change the path reference to /opt/etc/ssl/certs.

Check OpenSSL version:
Code: 
/tmp/home/root:#openssl version
OpenSSL 1.0.2p  14 Aug 2018
What router model and firmware version are you using?

Also, please paste code snip in the code brackets. You can use the
upload_2018-10-24_18-31-35.png
icon. Helps with the formatting and readability. Thanks!
 
Last edited:
You must log in or register to reply here.

Similar threads

RMerlin
Release Asuswrt-Merlin 3006.102.1 is now available for Wifi 7 devices
4 5 6
Replies
106
Views
17K
jksmurf
J
RMerlin
ANNOUNCEMENT: Asuswrt-Merlin support underway for 3 Wifi 7 routers
5 6 7
Replies
130
Views
27K
scasapending
S
DMcD-EMS-USMC
  • Locked
3006.102 alpha 2 Build(s) Now Available
Replies
2
Views
1K
octopus
octopus
RMerlin
Release Asuswrt-Merlin 3006.102.2 is now available for Wifi 7 devices
2 3 4
Replies
62
Views
7K
RMerlin
RMerlin
octopus
  • Locked
[ 3006.102 alpha Build(s) ] Testing available build(s)
2 3
Replies
59
Views
11K
octopus
octopus
Similar threads
Thread starter Title Forum Replies Date
RMerlin Release Asuswrt-Merlin 3004.388.8_4 is now available Asuswrt-Merlin 71
RMerlin Release Asuswrt-Merlin 3006.102.2 is now available for Wifi 7 devices Asuswrt-Merlin 62
B Unable to establish VPN connection to my PiVPN (ovpn) from my Asus RT-AC86U running Asuswrt-Merlin 386.14 Asuswrt-Merlin 1
F Several Questions Re:Asuswrt-Merlin Feature Implementation Asuswrt-Merlin 2
Yota How to enable port randomization in Asuswrt-Merlin? Asuswrt-Merlin 4
RMerlin Beta Asuswrt-Merlin 3006.102.2 Beta is now available for Wifi 7 devices Asuswrt-Merlin 70
J Does Asuswrt-Merlin support AiMesh over Wifi? Asuswrt-Merlin 4
Siff Printing from Guest Network (ASUSWRT-Merlin 3004.388.8_2) Asuswrt-Merlin 5
Siff Setting dnsmasq on Asuswrt-Merlin Asuswrt-Merlin 8
Rob Bowlby fwupdate.asuswrt-merlin.net - diversion.ch Down? Asuswrt-Merlin 7

Similar threads

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!

Members online

Total: 847 (members: 26, guests: 821)
Top