[erlang-bugs] possible bug in ssl and/or public_key module (R13 and R14)

[Ingela Anderton Andin]

Hi!

Filipe David Manana wrote:
> Just a few more questions,
>
> 1) are the 'verify_fun' and 'cacertfile' options meant to be used 
> together or are they mutually exclusive?
>
They are by no means mutually exclusive, and  can be  used together.  
If  you do not have  a  'cacertfile'  (or cacerts option)
you will always get the path-validation error unknown_ca.  (As you can 
not validate a CA that you do not know by other means than the 
certificate path sent to you.)
If you do not specify a a verify fun, all path validation errors will be 
treated as failures  and you will not get a connection.
The verify fun is there to let the application decide if it wants to 
accept some path validation errors such as for instance unknown_ca.
The verify fun is used in verify_peer-mode.  In verify_none mode is a 
little bit different depending on if you are server or client. In 
verify_none
mode the server will not request the client to send a certificate and 
hence there will be be no path-validation. The client will always 
receive a certificate
and go through the path-validation. So we are still discussion on how 
"generous" verify_none for the client should be.

> 2) Trying to do this on Ubuntu:
>
> {cacertfile, "/etc/ssl/certs/ca-certificates.crt"}
>
> That file, is a list o PEM encoded certificate:
>
> $ file /etc/ssl/certs/ca-certificates.crt
> /etc/ssl/certs/ca-certificates.crt: PEM certificate
>
> However I get the following exception when I pass that option:
>
> ** exception error: no match of right hand side value {error,ecacertfile}
>      in function  ssl_test:test/0
>
> =ERROR REPORT==== 17-Sep-2010::18:33:04 ===
> SSL: 1056: error:{error,
>                   {badmatch,
>                    {error,
>                     {asn1,
>                      {'Type not compatible with table constraint',
>                       {{badmatch,{error,{asn1,{wrong_tag,{5,16}}}}},
>                        [{'OTP-PUB-KEY','dec_Dss-Parms',2},
>                         {'OTP-PUB-KEY',dec_SignatureAlgorithm,2},
>                         {'OTP-PUB-KEY',dec_OTPTBSCertificate,2},
>                         {'OTP-PUB-KEY',dec_OTPCertificate,2},
>                         {'OTP-PUB-KEY',decode,2},
>                         {pubkey_cert_records,decode_cert,1},
>                         {public_key,pkix_decode_cert,2},
>                         {ssl_certificate_db,add_certs,3}]}}}}}} 
> /etc/ssl/certs/ca-certificates.crt
>   [{ssl_connection,init_certificates,2},
>    {ssl_connection,ssl_init,2},
>    {ssl_connection,init,1},
>    {gen_fsm,init_it,6},
>    {proc_lib,init_p_do_apply,3}]
>
> Is this a bug? The ssl man page mentions the file is in the PEM format.
> The file contents can be looked at:  
> http://friendpaste.com/4lQn7yihrUa4fE2Vs4u7JS
>
I have not verified this yet, but I think this looks like a bug in 
public_key that I have been working on solving that has to do with that
certs may inherit  DSS-Params from their issuer.

> 3) For the verify function, it receives {bad_cert, unknown_ca} when a 
> certificate is self-signed? I would like to distinguish between 
> unknown CAs and self-signed certificates (certificate signed by the 
> target host).
>
I think you have a point here we will look in to this.

Regards Ingela Erlang/OTP- team - Ericsson AB