Invalid license: Your evaluation license of RefinedTheme expired.

We can make you feel safe :-)


If you'd like to tell me I need to install a package like ca_root_nss or recommend a FreeBSD 8.x howto:

Yes, I've had at least 5 people trying to tell me how to add the normal CA bundles to a system. That is not the point. Please do read on to you see what this is about, and hopefully it'll help you at some point in the future.

Thank you for your patience.




  • be able to use a cert signed by CACert in any of the common SSL-capable applications on a FreeBSD host
  • accordingly, use any private CA you want


  • Only adding "all" root CA certificates as per the Mozilla bundle or other similar OpenSSL bundles
  • Adding a certificate for your web server
  • Do it on another FreeBSD version than 10.1
  • Do it in any way that is not persistent across upgrades of i.e. the ca_root_nss package




This is what OpenSSL will tell you if you don't have the certificate deployed

$ openssl s_client -connect my-test-server:443
depth=0 CN = my-test-server
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = my-test-server
verify error:num=27:certificate not trusted
verify return:1
depth=0 CN = my-test-server
verify error:num=21:unable to verify the first certificate
verify return:1
Certificate chain
 0 s:/CN=my-test-server
   i:/O=Root CA/OU= Cert Signing Authority/
 1 s:/O=CAcert Inc./OU= Class 3 Root
   i:/O=Root CA/OU= Cert Signing Authority/
Server certificate
[...more stuff......]
[...lots of stuff...]
    Verify return code: 21 (unable to verify the first certificate)


So, in this case we can *see* that CACert had already signed this off, but we also get informed that OpenSSL has no reason at all to trust any of the information in this certificate.

Any piece of the certificate chain needed to do that is *missing.*

OpenSSL from base

create the missing directories for the base OpenSSL.

mkdir /etc/ssl/{certs,private}

I'm very much worried by their non-existance, since this has to mean they are _not_ meant to be used. There has to be some reason, and I'm not aware of many OS that have OpenSSL, but not the certs/private dirs. I tried to find out more, but didn't get any comprehensive, conclusive and as such reliable information.

So, lets just do it like on any other OS.



Download the certificates

We'll store them right in /etc/ssl/certs.

First, the root Cert:

wget -O/etc/ssl/certs/cacert-root.crt


Second, the signing CA Cert:

wget -O/etc/ssl/certs/cacert-class3.crt 

I'll not advise you to validate their fingerprints since CACert delivers them via http and so it's rather useless anyway. Anyone could have intercepted you already.


Each needs an accompanying symlink or the OpenSSL version in FreeBSD won't read them.



Once the symlink is in place for both files you should see the following in /etc/ssl



and the following in /usr/local/something




If that is matching, you can try to validate the issuing CA cert using the CACert root certificate.

This is done using 


and should end with the following output, where I've marked the really important bits:




With that in place you can now trying to validate a CACert signed certificate using openssl's client mode

openssl s_client -connect <dsajfkjsdkfjksdfjdkf>:443 <opts>


If it worked you can also once more validate the chain

This is basically pointless if the above returned 0, but maybe we should use this?



Now, OpenSSL (base) should be fine.


OpenSSL from ports

If the Ports OpenSSL was installed and configured to replace the base OpenSSL (overwrite_base) you don't need to do anything special.

If you run both OpenSSL installs,you'll need to add symlinks for the certs and private folders in /etc/ssl to 

either /usr/local/etc/openssl or /usr/local/etc/ssl (it's not like you can find a non shit documentation on that)

Create symlinks for certs, private to link /etc/ssl and /usr/local/etc/openssl/ (or /usr/local/etc/ssl, it is still unclear)

As long as the symlinks are in place openssl from ports will be behaving the same on this.



Other software

Mozilla NSS

Comes with its own fucking closed certificate bundle

If you add your certificates to it they will be lost on the next update of the bundle by mozilla.

Yet people will tell you that is what to do.

It seems Mozilla will read addon certificates placed in the moz_nss bundle path.



When it's not working, you will likely get either an error 51 or 60. 60 Means the CA Cert is missing, 51 means you have a hostname mismatch.

Comes with its own fucking closed certificate bundle in FreeBSD

Curls official update website for updating the bundle is:

Accordingly you could update it using

let's use wget just to make a point?


The CACert certificate is not part of the bundle anyway, so what do we do?

It can be symlinked to the mozilla nss bundle most probably!

Output when broken
$ curl https://my-test-server/
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here:

curl performs SSL certificate verification by default, using a "bundle"
 of Certificate Authority (CA) public keys (CA certs). If the default
 bundle file isn't adequate, you can specify an alternate file
 using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
 the bundle, the certificate verification probably failed due to a
 problem with the certificate (it might be expired, or the name might
 not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
 the -k (or --insecure) option.

To fix:



Once you have a working setup, you should see the following

Output when OK




Comes with its own fucking closed certificate bundle which while only be update if you update python-requests (so, i.e. no idiot had been using virtualenv to version-lock it till end of the universe. Also, of course noone is making any guarantees that this package would actually ever be updated.

SLES has this abomination patched to not include the bundle but use the OS one instead.

It can be symlinked to the mozilla nss bundle most probably (it can definitely be linked against the shit update-ca-certifcates produces on CentOS)

Output when broken
$ python
>>> import requests
>>> a = requests.get(url="https://my-test-server/")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python2.7/site-packages/requests/", line 60, in get
    return request('get', url, **kwargs)
  File "/usr/local/lib/python2.7/site-packages/requests/", line 49, in request
    return session.request(method=method, url=url, **kwargs)
  File "/usr/local/lib/python2.7/site-packages/requests/", line 457, in request
    resp = self.send(prep, **send_kwargs)
  File "/usr/local/lib/python2.7/site-packages/requests/", line 569, in send
    r = adapter.send(request, **kwargs)
  File "/usr/local/lib/python2.7/site-packages/requests/", line 420, in send
    raise SSLError(e, request=request)
requests.exceptions.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581)

To fix:



Once you have a working setup, you should see the following

Output when OK




PKG can use SSL for two things:

Fetching the audit data (defaults to http, not https. CHANGE IT!)

Downloading your packages and verifying them.

This a larger topic, expect a few months till I have it well-documented.

pkg uses libfetch under the hood which in turn accesses relies on the ca_root_nss package.



One other interesting goal is to enable enough SSL verification to detect things like the useless self-signed cert one of the European FreeBSD SVN mirrors had been using.