Posted by: fdmanana | September 24, 2010

The new SSL implementation in Erlang OTP

Recently, I was trying the new SSL implementation of OTP. This new implementation appeared in the R12 series and is now the default one in R14. Unlike the “old” implementation, this one is mostly done in Erlang (instead of being basically a wrapper around the OpenSSL library) and only uses the cryptographic functions that the OpenSSL library provides.

The motivation to try it out, was that I was having often (but not very often) errors like the following from the “old” SSL implementation:

** {error,{badinfo,{tcp,#Port,

(Yes, this was CouchDB related). So I tried the following code in OTP R13B03 and R13B04:

test() ->
    Body = iolist_to_binary([
        "GET / HTTP/1.1\r\n",
        "Host: ", ?HOST, "\r\n",
        "Accept: */*\r\n",
        "Connection: close\r\n", "\r\n"
    Options = [
                {ssl_imp, new},
                {nodelay, true},
                {active, false},
                {verify, verify_peer},
                {depth, 3},
                {cacertfile, "/etc/ssl/certs/ca-certificates.crt"}
    {ok, S} = ssl:connect(?HOST, 443, Options),
    ok = ssl:send(S, Body),

loop(S) ->
    ssl:setopts(S, [{active, once}]),
    {ssl, S, Data} ->
        io:format("received data:  ~p~n", [Data]),
    {ssl_closed, S} ->
        io:format("socket closed", []);
    {ssl_error, S, Error} ->
        io:format("socket error:  ~p", [Error])

And I was getting the following stack trace when ssl:connect/3 was called:

=ERROR REPORT==== 17-Sep-2010::18:33:04 ===
SSL: 1056: error:{error,
                     {'Type not compatible with table constraint',
                        {ssl_certificate_db,add_certs,3}]}}}}}} /etc/ssl/certs/ca-certificates.crt

I was finding it weird, since the trusted certificates files I was providing was in the PEM format (supported according to the man page) and it worked with the “old” SSL implementation.

I posted a message to the erlang-bugs mailing list reporting the issue, since it seemed to me that it was a regression:

It turned out to be a true regression.
Fortunatelly, Ingela Anderton Andin, from the OTP team, quickly responded and worked on a few patches against the R14B release that I tried out until it worked. Those patches are all available at her github account:

(I must say github is one of my favourite free services on the Web, congratulations to the creators and maintainers).

A special thanks to Ingela for her quick response.
I squashed the relevant commits into a single patch to apply against R14B and it’s available here:

Since Ubuntu is using R13B03 and can not update to R14B so soon (it’s a very recent release and besides desktopcouch/couchdb, they have other Erlang OTP dependents), I prepared them an equivalent patch to apply against R13B03 (the ssl and public_key code has quite a lot of diferences between R13 and R14), available in the following github gist:

Also, as part of that same erlang-bugs thread, it was also proposed a suggestion for adding an extra possible value passed to the certificate validation chain function (option verify_fun) that allows for distinguishing between unknown CAs (not listed in the trusted certificates file) and certificates self-signed by the peer (something common in intranets). This because currently, as of R14B, the term {bad_term, unknown_ca} is used to signal both cases (unknown CA and self-signed ceritificate.

It turns out that the suggestion was accepted by the OTP team and is now available in development branches (will make it into the next OTP R14 series release):

After that commit, an unknown CA error is still represented by the term {bad_cert, unknown_ca} and a self-signed certificate is now represented by the term {bad_cert, selfsigned_peer} (the “old” SSL implementation allowed to distinguish both cases as well).


If you use the new SSL implementation (default on R14), don’t except to be able to use the certificates file in a Ubuntu system (and also in a Linux Caixa Mágica system). You’ll have to apply one of those patches available in the gists mentioned above.

I’m a bit surprised that I was the first one finding and reporting this issue/regression.

A big thanks to Ingela Andin from the OTP team for the quick response.


Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s


%d bloggers like this: