[erlang-bugs] {error, ekeyfile} when using new ssl implementation
mayamatakeshi
mayamatakeshi@REDACTED
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 <
ingela@REDACTED> 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 <
>> ingela@REDACTED <mailto:ingela@REDACTED**se<ingela@REDACTED>>>
>> 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:
>>
>> [root@REDACTED 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
>> erlang-bugs@REDACTED <mailto:erlang-bugs@REDACTED**>
>> 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.htm>
More information about the erlang-bugs
mailing list