curl-users
Re: curl: (35) error:14094412:SSL routines:SSL3_READ_BYTES:sslv3
Date: Tue, 8 Mar 2011 10:45:34 -0800
Daniel Stenberg writes:
> On Fri, 4 Mar 2011, Don Cohen wrote:
>
> > > curl: (35) error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert
> > > bad certificate
>
> > It seems that this error comes from the server. I wish curl could tell me
> > what part of the error is its own message and what part came from the
> > server.
>
> libcurl only provides a single error string so there's no distinction, and
> also that error is not coming from the server. It is an error that OpenSSL
> reports when communicating with the server, and libcurl reports that as it
> might help.
"an error that OpenSSL reports when communicating with the server" is
ambiguous here. Can you please explain?
What exactly is this error? What is the bad certificate? Is the
error in trying to READ the certificate, as the message suggests?
I believe the problem is really that the server is complaining about
the certificate. I suspect that's what the "alert" is all about -
I can see in the packet stream that the client receives an alert
message from the server and this is somehow related to that alert.
I don't get the same error when I send the same stuff to another
server so there's no problem with my certificate.
In any case I wish the error message could tell me enough about the
problem so I don't end up with all these questions. A url that
explains the errors in detail would be particularly useful.
> > --key <key>
> > (SSL) Private key file name. Allows you to provide your private
> > key in this separate file.
> > This evidently means that if you use --key then the -E need not
> > contain your private key. I wish the man page mentioned that under
> > the -E argument.
>
> It does: "See --cert and --key to specify them independently."
I don't see this in my man page.
> > In fact it would be better not to even allow this concatenated version,
>
> We take pride on not breaking backwards compatibility without very
> careful considerations and in this case I see no reason at all to
> do it.
Ok, I can appreciate the backward compatibility.
But at least the man page should lead you in the right direction.
Here's what I see on the man page:
-E/--cert <certificate[:password]>
(HTTPS) Tells curl to use the specified certificate file when
getting a file with HTTPS. The certificate must be in PEM for-
mat. If the optional password isn't specified, it will be
queried for on the terminal. Note that this certificate is the
private key and the private certificate concatenated!
If this option is used several times, the last one will be used.
I think it should say something like
-E/--cert <certificate[:password]>
(HTTPS) Tells curl to use the specified certificate file when
getting a file with HTTPS. In this case you also have to
supply your private key. Normally this is done with --key, but
for backward compatibility, it is also possible to concatenate
the private key and the certificate
(does order matter? need a newline between them?)
and pass the name of the resulting file as the -E argument.
The certificate must be in PEM format. If the optional password
(is needed and ?)
isn't specified, it will be queried for on the terminal.
If this option is used several times, the last one will be used.
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-users
FAQ: http://curl.haxx.se/docs/faq.html
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2011-03-08