[erlang-bugs] {error, ekeyfile} when using new ssl implementation

mayamatakeshi <>
Wed Mar 7 03:54:14 CET 2012


Hello,
I have 2 key files: one for sandbox APNs environment and another for the
production environment.

The structure of the files is like this:

Certificate1
RsaPrivateKey1
Certificate2
RsaPrivateKey2

So I separated them in

Certificate1
RsaPrivateKey1

Certificate2
RsaPrivateKey2

In the sandbox pem file, the pairs are identical.
But in the production pem file, they are not:
  Certificate1 != Certificate2
but
  RsaPrivateKey1 == RsaPrivateKey2

Also, I verified that only
  Certificate1
  RsaPrivateKey1
works (production).

I don't know if there will be any implications ahead, but so far having the
pem with just Certificate1+RsaPrivateKey1 is working fine.

Regards,
Takeshi


On Tue, Mar 6, 2012 at 5:11 PM, Ingela Anderton Andin <
> wrote:

> Hi!
>
> Out of curiosity are the two key entries the same key or different keys? A
> certificate is signed by one key only.  But  Pem  files  may contain any
> number of entries.
>
> Regards Ingela Erlang/OTP team Ericsson AB
>
> mayamatakeshi wrote:
>
>> Hi Ingela,
>> I don't know the reason about the two keys: I got the pem file from an
>> iphone app developer. I believe this is how Apple generates the files to be
>> used to connect to its servers (APNs).
>> But so I tried removing one of the keys and it worked with ssl new
>> implementation.
>> Thanks for the tip.
>>
>> Regards,
>> Takeshi
>>
>> On Mon, Mar 5, 2012 at 5:41 PM, Ingela Anderton Andin <
>>  <mailto:**se<>>>
>> wrote:
>>
>>    Hi!
>>
>>    The problem is that your file includes two keys and new ssl only
>>    expects there to be one.  old ssl was only a glue on top of openssl so
>>    the keyfile was then passed to openssl.  So it looks like openssl
>>    will pick a key if there is more than one.  In a future extension
>>    of the ssl application
>>    there might be a reason to handle more keys, but at the moment I
>>    am not sure what would be the correct thing to do, we could of
>>    course always pick the
>>    first key or something like that if  it will preserve some kind of
>>    backwards compatibility.  Do you know why your file contains two
>>    keys? That could
>>    help determining what to do.
>>
>>    Regards Ingela Erlang/OTP team - Ericsson AB
>>
>>    mayamatakeshi wrote:
>>
>>        Hello,
>>        I have this keyfile that I use with the old SSL implementation
>>        and it works fine with this code:
>>
>>        -module(ssl_test).
>>        -export([connect/0]).
>>
>>        connect() ->
>>               ssl:start(),
>>
>>               Address = "gateway.sandbox.push.apple.**com<http://gateway.sandbox.push.apple.com>
>>        <http://gateway.sandbox.push.**apple.com<http://gateway.sandbox.push.apple.com>
>> >
>>        <http://gateway.sandbox.push.**apple.com<http://gateway.sandbox.push.apple.com>
>> >",
>>
>>               Port = 2195,
>>               CaCert = "entrust_root_certification_**authority.pem",
>>               Cert = "server_cerificates_bundle_**sandbox.pem",
>>               Key = "server_cerificates_bundle_**sandbox.pem",
>>
>>               Options = [{cacertfile, CaCert}, {certfile, Cert},
>>        {keyfile, Key}, {mode, binary}, {ssl_imp, old}],
>>               Timeout = 1000,
>>               ssl:connect(Address, Port, Options, Timeout).
>>
>>
>>        However, when I try to use the new ssl implementation, I get this:
>>
>>        [ erlang]# erl
>>        Erlang R15B (erts-5.9) [source] [64-bit] [smp:2:2]
>>        [async-threads:0] [hipe] [kernel-poll:false]
>>
>>        Eshell V5.9  (abort with ^G)
>>        1> ssl_test:connect().
>>        {error,ekeyfile}
>>        2>
>>        =ERROR REPORT==== 4-Mar-2012::12:08:29 ===
>>        SSL: 1093: error:[{'RSAPrivateKey',<< .... >>,
>>                                          not_encrypted},
>>                         {'RSAPrivateKey',<< .... >>,
>>                                          not_encrypted}]
>>        server_cerificates_bundle_**sandbox.pem
>>         [{ssl_connection,init_private_**key,5,
>>                          [{file,"ssl_connection.erl"},{**line,1085}]},
>>                 {ssl_connection,ssl_init,2,[{**
>> file,"ssl_connection.erl"},{**line,1027}]},
>>                 {ssl_connection,init,1,[{file,**
>> "ssl_connection.erl"},{line,**305}]},
>>          {gen_fsm,init_it,6,[{file,"**gen_fsm.erl"},{line,343}]},
>>          {proc_lib,init_p_do_apply,3,[{**file,"proc_lib.erl"},{line,**
>> 227}]}]
>>
>>
>>        The server_cerificates_bundle_**sandbox.pem file has this format:
>>
>>        Bag Attributes
>>           friendlyName: XXXXXXXX
>>           localKeyID: XXXXXX
>>        subject=XXXXXXX
>>        issuer=XXXXXXX
>>        -----BEGIN CERTIFICATE-----
>>        XXXXXXXXXX
>>        -----END CERTIFICATE-----
>>        Bag Attributes
>>           friendlyName: XXXXXX
>>           localKeyID: XXXXXX
>>               subject=XXXXXXXXXX
>>        issuer=XXXXXXXXX
>>        -----BEGIN CERTIFICATE-----
>>        XXXXXXXXXXXX
>>        -----END CERTIFICATE-----
>>        Bag Attributes
>>           friendlyName: XXXXXXXXX
>>           localKeyID: XXXXXXXX
>>        Key Attributes: <No Attributes>
>>        -----BEGIN RSA PRIVATE KEY-----
>>        XXXXXXXXXXXXX
>>        -----END RSA PRIVATE KEY-----
>>        Bag Attributes
>>           friendlyName: XXXXXXXXXXX
>>           localKeyID: XXXXXXXXXXX
>>        Key Attributes: <No Attributes>
>>        -----BEGIN RSA PRIVATE KEY-----
>>        XXXXXXXXXXXXX
>>        -----END RSA PRIVATE KEY-----
>>
>>        So is this format supported by the new ssl implementation? Is
>>        this a bug?
>>        Or should I somehow convert this to a different format?
>>
>>        regards,
>>        Takeshi
>>
>>
>>        ------------------------------**------------------------------**
>> ------------
>>
>>        ______________________________**_________________
>>        erlang-bugs mailing list
>>         <mailto:**>
>>        http://erlang.org/mailman/**listinfo/erlang-bugs<http://erlang.org/mailman/listinfo/erlang-bugs>
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20120307/0eabc697/attachment.html>


More information about the erlang-bugs mailing list