[erlang-questions] Cowboy server, hackney client - SSL problems

Wed Jan 21 19:54:15 CET 2015

Hi Benoit,

The insecure option does the job for me. Thank you. I’m not concerned about strict certificate validation for the unit test and currently have no ability to test with a non self-signed cert.
I’m still quite new to the erlang scene and I will definitely dive deeper into the SSL validation topic. The problem is that there’s no in-depth knowledge on this subject easily available, most of it is rather difficult to find. Your ssl_verify_hostname project is a very good start.

Kind regards,

Radek Gruchalski

radek@REDACTED (mailto:radek@REDACTED)
 (mailto:radek@REDACTED)
de.linkedin.com/in/radgruchalski/ (http://de.linkedin.com/in/radgruchalski/)
+4917685656526

Confidentiality:
This communication is intended for the above-named person and may be confidential and/or legally privileged.
If it has come to you in error you must take no action based on it, nor must you copy or show it to anyone; please delete/destroy and inform the sender immediately.

On Wednesday, 21 January 2015 at 12:14, Benoit Chesneau wrote:

> How are you using curl against your custom certificate? Hackney is very strict by default unless you told it to be not and check only against valid cerificates. There are too way to bypass this protection:
>  
> - use the option `insecure` ewhen you do a request
> - use your own SSL options.  
>  
> Feel free to join me directly if you need it.
>  
> - benoit
>  
>  
> On Wed, Jan 21, 2015 at 2:59 PM, Rad Gruchalski <radek@REDACTED (mailto:radek@REDACTED)> wrote:
> > Hi everyone,
> >  
> > This is my first question on this mailing list. I have hit a wall while writing a bit of software which does the following: I have a REST-like server running on cowboy which runs on SSL, I’m using a self signed certificate generated by my own certificate authority, the settings I’m using in cowboy are:
> >  
> > [ { port, … },
> >   { cacertfile, absolute-path-to-the-public-cacert },
> >   { certfile, absolute-path-to-cert.pem },
> >   { keyfile, absolute-path-to-key.pem } ]
> >  
> > Cowboy starts fine, any request coming from CURL or Chrome browser is working fine, the clients are served, no issues whatsoever.
> >  
> > One of the parts of this software is a set of unit tests for the REST-like API. I am intending on using hackney for this. What happens is that when hackney client hits the API, cowboy fails with the following error message:
> >  
> > [error] SSL: certify: ssl_alert.erl:92:Fatal error: bad certificate
> >  
> > The error happens when hackney uses SSL options as cowboy server and with no SSL options.
> >  
> > I have verified my certificates in the following way: added it as a trusted cert in Chrome and Chrome does not complain about anything regarding the certificate anymore. I’ve also done the following:
> >  
> > openssl s_server -accept 8080 -cert ...cert.pem -key ...key.pem -CAfile …_ca.crt
> > Using default temp DH parameters
> > Using default temp ECDH parameters
> > ACCEPT
> > -----BEGIN SSL SESSION PARAMETERS-----
> > MHUCAQECAgMBBAIAOQQgzGrVgGBoyIRc9v3w3bqmiFQS3t6RjUfmaaa6AyCLsMgE
> > MFf7Tw9pR21yhGRTzuhEr8tXfOnlWKkl08eRS3bhld2jhHm3PgqB/0hinTw/f4CT
> > rqEGAgRUvyw9ogQCAgEspAYEBAEAAAA=
> > -----END SSL SESSION PARAMETERS-----
> > Shared ciphers:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:AES256-SHA:EDH-RSA-DES-CBC3-SHA:EDH-DSS-DES-CBC3-SHA:DES-CBC3-SHA:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:AES128-SHA:DHE-RSA-SEED-SHA:DHE-DSS-SEED-SHA:SEED-SHA:RC4-SHA:RC4-MD5:EDH-RSA-DES-CBC-SHA:EDH-DSS-DES-CBC-SHA:DES-CBC-SHA:EXP-EDH-RSA-DES-CBC-SHA:EXP-EDH-DSS-DES-CBC-SHA:EXP-DES-CBC-SHA:EXP-RC2-CBC-MD5:EXP-RC4-MD5
> > CIPHER is DHE-RSA-AES256-SHA
> > Secure Renegotiation IS supported
> >  
> > openssl s_client -connect localhost:8080  -cert ...cert.pem -key ...key.pem -CAfile …_ca.crt
> > CONNECTED(00000003)
> > depth=0 /CN=localhost/ST=Rheinland-Pfalz/C=DE/emailAddress=dev@REDACTED/O=dev@REDACTED (http://dev@somewhere.com/O=dev@somewhere.com)
> > verify error:num=18:self signed certificate
> > verify return:1
> > depth=0 /CN=localhost/ST=Rheinland-Pfalz/C=DE/emailAddress=dev@REDACTED/O=dev@REDACTED (http://dev@somewhere.com/O=dev@somewhere.com)
> > verify return:1
> > ---
> > Certificate chain
> >  0 s:/CN=localhost/ST=Rheinland-Pfalz/C=DE/emailAddress=dev@REDACTED/O=dev@REDACTED (http://dev@somewhere.com/O=dev@somewhere.com)
> >    i:/CN=localhost/ST=Rheinland-Pfalz/C=DE/emailAddress=dev@REDACTED/O=dev@REDACTED (http://dev@somewhere.com/O=dev@somewhere.com)
> > ---
> > Server certificate
> > -----BEGIN CERTIFICATE-----
> > MIIFhTCCA22gAwIBAgIJANOPgonG2vS4MA0GCSqGSIb3DQEBCwUAMHkxEjAQBgNV
> > BAMTCWxvY2FsaG9zdDEYMBYGA1UECBMPUmhlaW5sYW5kLVBmYWx6MQswCQYDVQQG
> > EwJERTEgMB4GCSqGSIb3DQEJARYRZGV2QGdvc3NpcGVybC5jb20xGjAYBgNVBAoU
> > EWRldkBnb3NzaXBlcmwuY29tMB4XDTE1MDEyMTAxMjkyN1oXDTE2MDEyMTAxMjky
> > N1oweTESMBAGA1UEAxMJbG9jYWxob3N0MRgwFgYDVQQIEw9SaGVpbmxhbmQtUGZh
> > bHoxCzAJBgNVBAYTAkRFMSAwHgYJKoZIhvcNAQkBFhFkZXZAZ29zc2lwZXJsLmNv
> > bTEaMBgGA1UEChQRZGV2QGdvc3NpcGVybC5jb20wggIiMA0GCSqGSIb3DQEBAQUA
> > A4ICDwAwggIKAoICAQDSPEXcaq4gdKyB6nGmac91sLNW2ZfBqJOWmkCIpYQnGB27
> > EUQTsdxqTtDkfEXlNjf6o4NupytDMqx7lRdVHh+Cqv38S8/Sb9FtyYtsxab4X9hv
> > vf063O455MKVGCeQGqOTmmQTfybCsiQAa8UYK/chS8wQeBLAIAAaVOcNtmEhbUpb
> > OaOkwInrjfK9lemD5J8G3z1oUDoiuxwoepyrEWGsmDEWLQKWNJmD6RLeHANH1/UQ
> > V0PNWqwwYPrkEp9hEgau25/NHrglE9OW1SJmL79Cy3DKvLGxwaH1U0K9vh4rEW3A
> > Vc36/TCVSpWXkxMUUDYHFihmR2oxyXSgs6/XKWSeV+xJD7VogljVJxl1IzAYcjlV
> > EbYT4KNqZaqAdSeriRAMSJ5LlZ+7/uknOfdqKcAwUUwdYKKdb1IHpiRmGjFso0zF
> > icMdKudNLZu854PIkSslh2/SJUhj2fiNwZ8QaGrnklJSEUE6jgjPBcAWbkY6M0Xm
> > QUON8LcuDGivh1HPOzgiHiWnkd2zGqwAg1u5vsLcraspXBPfgQc+v+oek5xi5OVL
> > K4YvB8iVf1dg8NQ1Xm3S+aPthi/eI/6UxSx3hSV2fPfydJ8JHoeRx2YWV3Q3dClG
> > iJJLg36pOoFmO6nMwDDIZpSvPwZsfa/S9A69ZuQMv7ra6o8rzfXo7ZtSvy2X0QID
> > AQABoxAwDjAMBgNVHRMEBTADAQH/MA0GCSqGSIb3DQEBCwUAA4ICAQCoinw+YKNs
> > 0amglVRGcgDJ4kQlz4HN9Z7phmc5MoEUzeo1vSUH/dvKu9tfgzdArRndXIVMOhqM
> > UiOJvfIFua+IZIO2VWqSgIiyuJ1NYYk3trceVu9BZFb8GC0zymG54kXfzcCejDxZ
> > K8hm3eSnTqHJWSFwqGW8OGDzoxfJJCtn6hivZJcyvz6lV0Gp+GxkKHqtDZxQpjCl
> > 4I7qyz9i7KOfARtca3VTNwQfaMWZSBZ9A7DoYEFvpIGu0faNmy4zbIM7eIKNhBid
> > v4xqkQHG8f/XTRhNYebBgCzmittKlQc61NodCGnQJXTcS/xZO8NVweAMmqzaR3A9
> > BAn9PZ1b/2hScDSAGtJEon3EToqzb5g2ijbKknshbNTe+Nt3J+Riyll115LZRSxg
> > qwFnPv56WRvL1wJLfYW/S2q9Vwa/RzTiPpPBHPdJw7TETh8Z3UshjSeDVDGmdiQC
> > V+vFxdMAVtvV7krfuwLa04NQ3mG+WrWfnbPUli7OzZ7NlUxG3Koc0QahABrIahlo
> > ZDe1yV1OxeSJZByBcM57N04LVDkK29TuqaQsieW/A80g9EN1Q6Y3AJOLhhyZ1Euq
> > bDg24BJ0P6FiuBz/WFtDRmjwfxhmPiZICfBqpQeltgKsungE4Lg8sMuxPFc7pJpm
> > hIedZIKnykXzT2wkzRuBz9F9EqyYNRA7BQ==
> > -----END CERTIFICATE-----
> > subject=/CN=localhost/ST=Rheinland-Pfalz/C=DE/emailAddress=dev@REDACTED/O=dev@REDACTED (http://dev@somewhere.com/O=dev@somewhere.com)
> > issuer=/CN=localhost/ST=Rheinland-Pfalz/C=DE/emailAddress=dev@REDACTED/O=dev@REDACTED (http://dev@somewhere.com/O=dev@somewhere.com)
> > ---
> > No client certificate CA names sent
> > ---
> > SSL handshake has read 2244 bytes and written 264 bytes
> > ---
> > New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
> > Server public key is 4096 bit
> > Secure Renegotiation IS supported
> > Compression: NONE
> > Expansion: NONE
> > SSL-Session:
> >     Protocol  : TLSv1
> >     Cipher    : DHE-RSA-AES256-SHA
> >     Session-ID: CC6AD5806068C8845CF6FDF0DDBAA6885412DEDE918D47E669A6BA03208BB0C8
> >     Session-ID-ctx:
> >     Master-Key: 57FB4F0F69476D72846453CEE844AFCB577CE9E558A925D3C7914B76E195DDA38479B73E0A81FF48629D3C3F7F8093AE
> >     Key-Arg   : None
> >     Start Time: 1421814845
> >     Timeout   : 300 (sec)
> >     Verify return code: 18 (self signed certificate)
> > —
> >  
> > ssl:versions().
> >  
> > [{ssl_app,"5.3.8"},
> >  {supported,['tlsv1.2','tlsv1.1',tlsv1,sslv3]},
> >  {available,['tlsv1.2','tlsv1.1',tlsv1,sslv3]}]
> >  
> >  
> > I am trying to understand why Erlang has a problem with it. I read that Erlang had a problem with sha256 signed certs but I am not sure if this is still a problem? I am using OTP 17.4 for these tests. The error happens in some unidentified place, I tried modifying OTP to log the error message in a place where there’s only reference to ?BAD_CERTIFICATE (via call to path_validation_alert function in ssl_handshake.erl) but I get no log - the modification can be seen here:  https://github.com/gossiperl/otp/blob/b446bcc3ece0367c96b54af96577b23e4fa43ee4/lib/ssl/src/ssl_handshake.erl#L433 and I am 100% that the installation of Erlang I’m using is the one with the modified code. Of course it could be an issue with my certificate.
> >  
> > I would appreciate any pointers.
> >  
> >  
> >  
> >  
> >  
> >  
> >  
> >  
> >  
> >  
> > Kind regards,

> > Radek Gruchalski
> > 
radek@REDACTED (mailto:radek@REDACTED)
 (mailto:radek@REDACTED)
> > de.linkedin.com/in/radgruchalski/ (http://de.linkedin.com/in/radgruchalski/)
> > +4917685656526 (tel:%2B4917685656526)
> >  
> > Confidentiality:
> > This communication is intended for the above-named person and may be confidential and/or legally privileged.
> > If it has come to you in error you must take no action based on it, nor must you copy or show it to anyone; please delete/destroy and inform the sender immediately.
> >  
> >  
> >  
> > _______________________________________________
> > erlang-questions mailing list
> > erlang-questions@REDACTED (mailto:erlang-questions@REDACTED)
> > http://erlang.org/mailman/listinfo/erlang-questions
> >  
>  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20150121/ba7da6b8/attachment.htm>