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

Wed Jan 21 18:14:56 CET 2015

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>
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
> 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
> verify return:1
> ---
> Certificate chain
>  0 s:/CN=localhost/ST=Rheinland-Pfalz/C=DE/emailAddress=
> dev@REDACTED/O=dev@REDACTED
>    i:/CN=localhost/ST=Rheinland-Pfalz/C=DE/emailAddress=
> dev@REDACTED/O=dev@REDACTED
> ---
> 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
> issuer=/CN=localhost/ST=Rheinland-Pfalz/C=DE/emailAddress=
> dev@REDACTED/O=dev@REDACTED
> ---
> 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 <radek@REDACTED>
> 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.
>
> _______________________________________________
> erlang-questions mailing list
> 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/21a4ce30/attachment.htm>