pyopenssl-list

[pyOpenSSL] Tracking down a change in private key format

[Erinn Looney-T. <eri...@gm...>]

I am trying to track down a change in private key format that exists
between RHEL 5 and RHEL 6 systems and I believe that pyOpenSSL may be
responsible, though I am not sure.

RHEL 5 uses pyOpenSSL-0.6-2.el5
RHEL 6 uses pyOpenSSL-0.10-2.el6.x86_64

It appears that in RHEL 5 private keys were stored in OpenSSL's default
PEM format, e.g. starting with:
----BEGIN RSA PRIVATE KEY-----
-----END RSA PRIVATE KEY-----

In RHEL 6 this seems to have changed (using the same code to call) and
the format now appears to use PKCS#8 (for the code call it is an
unencrypted key):

-----BEGIN PRIVATE KEY-----
-----END PRIVATE KEY-----

>From OpenSSL's documentation it appears that PKCS#8 is still not the
default, so I am unsure as to why this is the format being output. The
code in question comes from certmaster: https://fedorahosted.org/certmaster/

The code (identical on RHEL 5 and RHEL 6):
def make_keypair(dest=None):
    pkey = crypto.PKey()
    pkey.generate_key(crypto.TYPE_RSA, 2048)
    if dest:
        destfd = os.open(dest, os.O_RDWR|os.O_CREAT, 0600)
        os.write(destfd, (crypto.dump_privatekey(crypto.FILETYPE_PEM,
pkey)))
        os.close(destfd)

    return pkey

Was this formatting change intentional or did it just happen due to some
change in OpenSSL? Just trying to nail down how this change came about,
because it ultimately lead to the syslog daemon core dumping as it tried
to load the private key.

Thanks,

-Erinn

Re: [pyOpenSSL] Tracking down a change in private key format

[<ex...@tw...>]

On 11 Oct, 10:03 pm, eri...@gm... wrote:
>I am trying to track down a change in private key format that exists
>between RHEL 5 and RHEL 6 systems and I believe that pyOpenSSL may be
>responsible, though I am not sure.
>
>RHEL 5 uses pyOpenSSL-0.6-2.el5
>RHEL 6 uses pyOpenSSL-0.10-2.el6.x86_64
>
>It appears that in RHEL 5 private keys were stored in OpenSSL's default
>PEM format, e.g. starting with:
>----BEGIN RSA PRIVATE KEY-----
>-----END RSA PRIVATE KEY-----
>
>In RHEL 6 this seems to have changed (using the same code to call) and
>the format now appears to use PKCS#8 (for the code call it is an
>unencrypted key):
>
>-----BEGIN PRIVATE KEY-----
>-----END PRIVATE KEY-----
>> From OpenSSL's documentation it appears that PKCS#8 is still not the
>default, so I am unsure as to why this is the format being output. The
>code in question comes from certmaster: 
>https://fedorahosted.org/certmaster/
>
>The code (identical on RHEL 5 and RHEL 6):
>def make_keypair(dest=None):
>    pkey = crypto.PKey()
>    pkey.generate_key(crypto.TYPE_RSA, 2048)
>    if dest:
>        destfd = os.open(dest, os.O_RDWR|os.O_CREAT, 0600)
>        os.write(destfd, (crypto.dump_privatekey(crypto.FILETYPE_PEM,
>pkey)))
>        os.close(destfd)
>
>    return pkey
>
>Was this formatting change intentional or did it just happen due to 
>some
>change in OpenSSL? Just trying to nail down how this change came about,
>because it ultimately lead to the syslog daemon core dumping as it 
>tried
>to load the private key.

Hiya Erinn,

The formatting change was not intentional.  I think that I noticed it 
when I was working on OpenSSL 1.0.0 compatibility.  Do you know if RHEL 
6 switched to OpenSSL 1.0.0 (or maybe they just back-ported the format 
change to their version of 0.9.8, which is the sort of thing Debian 
likes to do)?

I didn't think much of the change when I noticed it, and I didn't expect 
it to cause problems like the one you're describing, or I might have 
tried to have pyOpenSSL force the result to be the old format.  Instead, 
I just made the unit tests work with either format. :/

Jean-Paul

Re: [pyOpenSSL] Tracking down a change in private key format

[Erinn Looney-T. <eri...@gm...>]

On 10/12/2011 04:59 AM, ex...@tw... wrote:
> On 11 Oct, 10:03 pm, eri...@gm... wrote:
>> I am trying to track down a change in private key format that exists
>> between RHEL 5 and RHEL 6 systems and I believe that pyOpenSSL may be
>> responsible, though I am not sure.
>>
>> RHEL 5 uses pyOpenSSL-0.6-2.el5
>> RHEL 6 uses pyOpenSSL-0.10-2.el6.x86_64
>>
>> It appears that in RHEL 5 private keys were stored in OpenSSL's default
>> PEM format, e.g. starting with:
>> ----BEGIN RSA PRIVATE KEY-----
>> -----END RSA PRIVATE KEY-----
>>
>> In RHEL 6 this seems to have changed (using the same code to call) and
>> the format now appears to use PKCS#8 (for the code call it is an
>> unencrypted key):
>>
>> -----BEGIN PRIVATE KEY-----
>> -----END PRIVATE KEY-----
>>> From OpenSSL's documentation it appears that PKCS#8 is still not the
>> default, so I am unsure as to why this is the format being output. The
>> code in question comes from certmaster: 
>> https://fedorahosted.org/certmaster/
>>
>> The code (identical on RHEL 5 and RHEL 6):
>> def make_keypair(dest=None):
>>    pkey = crypto.PKey()
>>    pkey.generate_key(crypto.TYPE_RSA, 2048)
>>    if dest:
>>        destfd = os.open(dest, os.O_RDWR|os.O_CREAT, 0600)
>>        os.write(destfd, (crypto.dump_privatekey(crypto.FILETYPE_PEM,
>> pkey)))
>>        os.close(destfd)
>>
>>    return pkey
>>
>> Was this formatting change intentional or did it just happen due to 
>> some
>> change in OpenSSL? Just trying to nail down how this change came about,
>> because it ultimately lead to the syslog daemon core dumping as it 
>> tried
>> to load the private key.
> Hiya Erinn,
>
> The formatting change was not intentional.  I think that I noticed it 
> when I was working on OpenSSL 1.0.0 compatibility.  Do you know if RHEL 
> 6 switched to OpenSSL 1.0.0 (or maybe they just back-ported the format 
> change to their version of 0.9.8, which is the sort of thing Debian 
> likes to do)?
>
> I didn't think much of the change when I noticed it, and I didn't expect 
> it to cause problems like the one you're describing, or I might have 
> tried to have pyOpenSSL force the result to be the old format.  Instead, 
> I just made the unit tests work with either format. :/
>
> Jean-Paul
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2d-oct
> _______________________________________________
> pyopenssl-list mailing list
> pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopenssl-list

Yeah RHEL 6 uses openssl-1.0.0-10.el6_1.4.x86_64. So is OpenSSL setting
the default to PKCS#8 now? If so they probably need to update their
documentation.

-Erinn