unbound SSL_CTX errors after upgrade

nforced

nforced

I just upgraded from 10.2-RELEASE to 10.3-RELEASE and after the second reboot I saw this:
Code: 
Starting local_unbound.
Waiting for nameserver to start...[1459794274] unbound-control[483:0] warning: control-enable is 'no' in the config file.
error: Error setting up SSL_CTX client key and cert
34388867800:error:02001002:system library:fopen:No such file or directory:/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/bio/bss_file.c:398:fopen('/var/unbound/unbound_control.pem','r')
34388867800:error:20074002:BIO routines:FILE_CTRL:system lib:/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/bio/bss_file.c:400:
34388867800:error:140DC002:SSL routines:SSL_CTX_use_certificate_chain_file:system lib:/usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/ssl_rsa.c:687:
.[1459794275] unbound-control[486:0] warning: control-enable is 'no' in the config file.
error: Error setting up SSL_CTX client key and cert
34388867800:error:02001002:system library:fopen:No such file or directory:/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/bio/bss_file.c:398:fopen('/var/unbound/unbound_control.pem','r')
34388867800:error:20074002:BIO routines:FILE_CTRL:system lib:/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/bio/bss_file.c:400:
34388867800:error:140DC002:SSL routines:SSL_CTX_use_certificate_chain_file:system lib:/usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/ssl_rsa.c:687:
.[1459794276] unbound-control[489:0] warning: control-enable is 'no' in the config file.
error: Error setting up SSL_CTX client key and cert
34388867800:error:02001002:system library:fopen:No such file or directory:/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/bio/bss_file.c:398:fopen('/var/unbound/unbound_control.pem','r')
34388867800:error:20074002:BIO routines:FILE_CTRL:system lib:/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/bio/bss_file.c:400:
34388867800:error:140DC002:SSL routines:SSL_CTX_use_certificate_chain_file:system lib:/usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/ssl_rsa.c:687:
.[1459794277] unbound-control[492:0] warning: control-enable is 'no' in the config file.
error: Error setting up SSL_CTX client key and cert
34388867800:error:02001002:system library:fopen:No such file or directory:/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/bio/bss_file.c:398:fopen('/var/unbound/unbound_control.pem','r')
34388867800:error:20074002:BIO routines:FILE_CTRL:system lib:/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/bio/bss_file.c:400:
34388867800:error:140DC002:SSL routines:SSL_CTX_use_certificate_chain_file:system lib:/usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/ssl_rsa.c:687:
.[1459794278] unbound-control[495:0] warning: control-enable is 'no' in the config file.
error: Error setting up SSL_CTX client key and cert
34388867800:error:02001002:system library:fopen:No such file or directory:/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/bio/bss_file.c:398:fopen('/var/unbound/unbound_control.pem','r')
34388867800:error:20074002:BIO routines:FILE_CTRL:system lib:/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/bio/bss_file.c:400:
34388867800:error:140DC002:SSL routines:SSL_CTX_use_certificate_chain_file:system lib:/usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/ssl_rsa.c:687:
giving up
Does anyone know why did this happened and how to solve it?
 
No, I didn't had that, but when I add it I get:
Code: 
#service local_unbound restart
local_unbound not running? (check /var/run/local_unbound.pid).
Starting local_unbound.
/var/unbound/unbound.conf:5: error: syntax error
read /var/unbound/unbound.conf failed: 1 errors in configuration file
[1459796363] unbound[1404:0] fatal error: Could not read config file: /var/unbound/unbound.conf
/etc/rc.d/local_unbound: WARNING: failed to start local_unbound
Without "control-enable: yes" I get the initial errors.
Anyway I wonder is this for PR or it's something on my side that needs to be done. Overall I don't think this should have happened at first place without a reason.
 
Code: 
remote-control:
       control-enable: no
Setting this in unbound.conf should not produce these weird messages, because Unbound works fine after spewing them, and setting it to no already tells Unbound to not initialise SSL/TLS. Those errors are not a good thing.
Code: 
error: Error setting up SSL_CTX client key and cert
That is really baloney, and unnecessarily alarmist.
 
nforced said:
No, I didn't had that, but when I add it I get:
Code: 
#service local_unbound restart
local_unbound not running? (check /var/run/local_unbound.pid).
Starting local_unbound.
/var/unbound/unbound.conf:5: error: syntax error
read /var/unbound/unbound.conf failed: 1 errors in configuration file
[1459796363] unbound[1404:0] fatal error: Could not read config file: /var/unbound/unbound.conf
/etc/rc.d/local_unbound: WARNING: failed to start local_unbound
Without "control-enable: yes" I get the initial errors.
Anyway I wonder is this for PR or it's something on my side that needs to be done. Overall I don't think this should have happened at first place without a reason.
Click to expand...

You need the category, see above. But that's the same as leaving it out entirely, because the default is already no. The screenfull of errors is not appreciated, by me anyway.
 
Ok did this what you have advised, I put
Code: 
remote-control:
    control-enable: yes
at the bottom of /etc/unbound/unbound.conf

and then I here's what happening:
Code: 
service local_unbound start
Starting local_unbound.
/etc/rc.d/local_unbound: WARNING: failed to start local_unbound
/var/log/messages
Code: 
Apr  4 22:13:56 beast unbound: [1600:0] error: Error for server-cert-file: /var/unbound/unbound_server.pem
Apr  4 22:13:56 beast unbound: [1600:0] error: Error in SSL_CTX use_certificate_chain_file crypto error:02001002:system library:fopen:No such file or directory
Apr  4 22:13:56 beast unbound: [1600:0] error: and additionally crypto error:20074002:BIO routines:FILE_CTRL:system lib
Apr  4 22:13:56 beast unbound: [1600:0] error: and additionally crypto error:140DC002:SSL routines:SSL_CTX_use_certificate_chain_file:system lib
Apr  4 22:13:56 beast unbound: [1600:0] fatal error: could not set up remote-control
Apr  4 22:13:56 beast booster: /etc/rc.d/local_unbound: WARNING: failed to start local_unbound
 
Of course, if you set it to yes you will have to set it up entirely, with the certificates and keys and everything. Very few people will actually need remote control of their resolvers. So set it to no (or remove it) and just swallow the horrible errors (for now).
 
DutchDaemon said:
Of course, if you set it to yes you will have to set it up entirely, with the certificates and keys and everything.
Click to expand...
Ok, I don't want this since I never had it and I really don't need it. So I removed that and got the initial warnings again, it's good that it works that way but still sad to see this output with control-enable: no so I wonder should I submit a PR on this or just leave it like that till someone fix it for some other reason?
 
I'm sure PRs will be lodged almost instantly, but it doesn't hurt.
 
nforced said:
Right, I just did that https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208529 let's see what will happen :)
Click to expand...

You should set up unbound-control correctly. From the unbound-control (8) man page:
SET UP
The setup requires a self-signed certificate and private keys for both
the server and client. The script unbound-control-setup generates
these in the default run directory, or with -d in another directory.
If you change the access control permissions on the key files you can
decide who can use unbound-control, by default owner and group but not
all users. Run the script under the same username as you have config-
ured in unbound.conf or as root, so that the daemon is permitted to
read the files, for example with:
sudo -u unbound unbound-control-setup​
If you have not configured a username in unbound.conf, the keys need
read permission for the user credentials under which the daemon is
started. The script preserves private keys present in the directory.
After running the script as root, turn on control-enable in
unbound.conf.​
Click to expand...
​
 
Setting it to no should never produce these errors, that is the point of the bug report.
 
Only today, I saw this also on my server, that I updated recently from RELEASE-10.2 to -10.3

I found the culprit. It lies in the local_unbound_poststart() sub-routine in file /etc/rc.d/local_unbound. Said sub-routine has been newly introduced with RELEASE-10.3 in order to:
/etc/rc.d/local_unbound said:
#
# After starting, wait for Unbound to report that it is ready to avoid
# race conditions with services which require functioning DNS.
#
Click to expand...

And for checking the online status of Unbound, somebody got the particularly bright idea to utilize the remote control tool unbound-control, which is disabled by default, and not properly setup on most machines, and in order to add insult to the injury, local_unbound_poststart() tries it 5 times before giving up.

In my file /etc/rc.d/local_unbound I commented out the body of local_unbound_poststart():
Code: 
#
# After starting, wait for Unbound to report that it is ready to avoid
# race conditions with services which require functioning DNS.
#
local_unbound_poststart()
{
#    local retry=5
#
#    echo -n "Waiting for nameserver to start..."
#    until "${command}-control" status | grep -q "is running" ; do
#        if [ $((retry -= 1)) -eq 0 ] ; then
#            echo " giving up"
#            return 1
#        fi
#        echo -n "."
#        sleep 1
#    done
#    echo " good"
}
This solved the problem for me. I am using Unbound since 2 years, and I never saw any race conditions, anyway. If we really need to check whether unbound is running, why not simply run drill localhost @127.0.0.1, or something similar along this line. The additional benefit of this would be, that the timing out feature is built-in to the drill(1) command.
 
Hmm, this is what I did today
Code: 
root@beast:~ > portmaster dns/unbound
root@beast:~ > unbound-control-setup
setup in directory /usr/local/etc/unbound
generating unbound_server.key
Generating RSA private key, 3072 bit long modulus
...................++
.................................................................................................................................................................++
e is 65537 (0x10001)
generating unbound_control.key
Generating RSA private key, 3072 bit long modulus
.............++
..........++
e is 65537 (0x10001)
create unbound_server.pem (self signed certificate)
create unbound_control.pem (signed client certificate)
Signature ok
subject=/CN=unbound-control
Getting CA Private Key
Setup success. Certificates created. Enable in unbound.conf file to use
root@beast:~ > /etc/rc.d/local
local*  local_unbound* localpkg*
root@beast:~ > /etc/rc.d/local
local*  local_unbound* localpkg*
root@beast:~ > /etc/rc.d/local_unbound restart
Stopping local_unbound.
Waiting for PIDS: 504.
Starting local_unbound.
Waiting for nameserver to start...[1460028235] unbound-control[1359:0] warning: control-enable is 'no' in the config file.
Same thing.
 
You can't mix local_unbound service and dns/unbound, they use totally different locations for binaries and configuration files. Assuming you want to have the control ability use the port only.
 
You can disable local_unbound service from base.

According to the man src.conf(5) there is an option called WITHOUT_UNBOUND, when it's set, will cause the unbound is not installed. Then set
Code: 
WITHOUT_UNBOUND=yes
in /etc/src.conf is the first step to prevent it from being reinstalled in an update.

After the parameter is in place, if you go to /usr/src and run make check-old
Code: 
Checking for old files
/etc/rc.d/local_unbound
/etc/unbound
/usr/sbin/local-unbound-setup
/usr/sbin/unbound
/usr/sbin/unbound-anchor
/usr/sbin/unbound-checkconf
/usr/sbin/unbound-control
/usr/sbin/unbound-control-setup
/usr/share/man/man5/unbound.conf.5.gz
/usr/share/man/man8/unbound-anchor.8.gz
/usr/share/man/man8/unbound-checkconf.8.gz
/usr/share/man/man8/unbound-control.8.gz
/usr/share/man/man8/unbound.8.gz
Checking for old libraries
/usr/lib/private/libunbound.so.5
/usr/lib32/private/libunbound.so.5
Checking for old directories
To remove old files and directories run 'make delete-old'.
To remove old libraries run 'make delete-old-libs'.

The files currently installed from unbound already enter the obsolete list, and can be removed to make delete-old and make delete-old-libs
 
Thanks cpm, I don't want to disable this service, I use it for my own needs I just want to have it running like I aways used to. I know disabling it will solve the problem, but thats not my point.
 
nforced said:
I have tried this, same problem there...
Click to expand...
I guess you misunderstood the suggestion. Installing dns/unbound is not sufficient. You need to tell your system to use it instead of local_unbound from the base system. To begin with, you would need to copy the settings from /etc/unbound/unbound.conf (the base location) to /usr/local/etc/unbound/unbound.conf, i.e. the settings location of the Unbound port. In addition, the start command is of course not
Code: 
local_unbound_enable="YES"
but simply
Code: 
unbound_enable="YES"
There is no need to remove local_unbound, only make sure, you don't activate it in file /etc/rc.conf.

Anyway, installing dns/unbound and transferring all the settings, is IMHO much more hassle than simply deactivating the culprit local_unbound_poststart() subroutine in /etc/rc.d/local_unbound. I added a comment on your PR 208529 on this.
 
obsigna said:
I found the culprit. It lies in the local_unbound_poststart() sub-routine in file /etc/rc.d/local_unbound.

In my file /etc/rc.d/local_unbound I commented out the body of local_unbound_poststart():
Code: 
#
# After starting, wait for Unbound to report that it is ready to avoid
# race conditions with services which require functioning DNS.
#
local_unbound_poststart()
{
#    local retry=5
#
#    echo -n "Waiting for nameserver to start..."
#    until "${command}-control" status | grep -q "is running" ; do
#        if [ $((retry -= 1)) -eq 0 ] ; then
#            echo " giving up"
#            return 1
#        fi
#        echo -n "."
#        sleep 1
#    done
#    echo " good"
}
This solved the problem for me. I am using Unbound since 2 years, and I never saw any race conditions, anyway. If we really need to check whether unbound is running, why not simply run drill localhost @127.0.0.1, or something similar along this line. The additional benefit of this would be, that the timing out feature is built-in to the drill(1) command.
Click to expand...

Thanks, that helped me.
I prefer to use bundled unbound on lower-load servers to pay less attention for updates, while install dns/unbound on busy servers with more options available for high load.

Also, in default config /etc/unbound/unbound.conf.sample it is chroot enabled by default, with mismatched pid-file location, by default inside in config and outside in /etc/rc.d/local_unbound script

diff:
Code: 
- # pidfile: "/etc/unbound/unbound.pid"
+pidfile: "/var/run/local_unbound.pid"
 
You must log in or register to reply here.
Back
Top