[openssl-users] Question as to best options....

Fri Dec 29 00:11:02 UTC 2017

On 12/28/2017 16:57, Karl Denninger wrote:
> On 12/28/2017 16:15, Karl Denninger wrote:
>> On 12/26/2017 14:07, Kurt Roeckx wrote:
>>> On Tue, Dec 26, 2017 at 01:42:57PM -0600, Karl Denninger wrote:
>>>> On 12/26/2017 13:14, Salz, Rich via openssl-users wrote:
>>>>> So if you put locks around the SSL_CTX object when it’s used, then you
>>>>> can use the set private key call to update the key; and then all
>>>>> SSL_new objects afterwards will use the new credentials.  Does that
>>>>> meet your need?
>>>>>
>>>> Yes, that I already know how to do.  The issue is how to get the key
>>>> from a PEM file into a format that I can feed it with set private key. 
>>>> There doesn't appear to be a means to "un-file-ify" the set private key
>>>> functions.
>>> You can use the d2i_PrivateKey and i2d_PrivateKey functions to read
>>> and write the file.
>>>
>>>>>> "is there a decent way to convert a PEM or DER private key file into
>>>>> ASN.1" using OpenSSL calls (from a "C" program, not from the command
>>>>> line; we'll assume I have the key and cert files already.)
>>>>>
>>>>> I assume you mean “native C structure” and not ASN1?  Because DER is
>>>>> just the ASN1 serialized, and PEM is base64 encoded DER with marker
>>>>> lines. …
>>>>>
>>>>>
>>>>>
>>>> So if I take a PEM private key file, strip the markers, and turn the
>>>> actual key's base64 into binary (assuming an RSA key, so there's no "EC
>>>> parameter" block in front) I now have an "opaque" unsigned character
>>>> array of length "len" (the decoded Base64) which
>>>> SSL_CTX_use_privateKey_ASN1 will accept?  (Assuming the key file is
>>>> unencrypted, of course.)
>>>>
>>>> What is the parameter "pk" passed to the call in that instance (it's not
>>>> in the man page)
>>> From the manpage:
>>> SSL_CTX_use_PrivateKey_ASN1() adds the private key of type _pk_
>>>
>>> So you would need to know that it's an RSA or EC key. If you used
>>> d2i_AutoPrivateKey you don't need to know the type and get an
>>> EVP_PKEY.
>>>
>>>
>>> Kurt
>> Not sure what I'm doing wrong here but obviously its something!
>>
>> certtemp = *char
>> certstore = unsigned char*  (Both with enough allocated memory to
>> hold the required data, of course)
>> const unsigned char *p;
>>
>> certstore has the Base64 key in it (checked manually, I am reading it
>> properly from the key file with the barrier lines and line feeds
>> omitted.)
>>
>>        .......
>>
>>         strcpy((char *) certstore, certtemp);
>>         p = certstore;
>>         key = d2i_AutoPrivateKey(NULL, &p, strlen(certtemp));
>>         if (key == NULL) {
>>                 ERR_error_string(ERR_get_error(), tmp);
>> >>           return(NULL);
>>         }
>>
>>         ......
>>
>> But I get
>>
>> $4 = 0xbf3f9b90 "error:0D0680A8:asn1 encoding
>> routines:ASN1_CHECK_TLEN:wrong tag"
>> in tmp and a NULL key return from d2i_AutoPrivateKey at the ">>"
>> breakpoint.
>>
>> If I convert the base64 to binary first -- using the Base64 routine
>> in OpenSSL (which I know I've coded correctly as the code in question
>> uses it elsewhere to decode a MIME attachment) and pass a binary
>> buffer and the length of that buffer (instead of a base64 buffer and
>> its length) I still get NULL back for the EVP_PKEY structure and the
>> same error text in tmp.
>>
>> If I load that same key file with (having put the path to the key
>> file in tmp) with:
>>
>> if (SSL_CTX_use_PrivateKey_file(www_context, tmp, SSL_FILETYPE_PEM) <
>> 0) {.....
>>
>> It loads and works.
>>
>> What's even MORE odd is that if I do this with the SAME key data I
>> just loaded in base64 (knowing it's an RSA key):
>>
>>          len = (strlen(certtemp) * 3) / 4 +1;
>>          cbin = decode_base64(certtemp, strlen(certtemp));
>>          if (SSL_CTX_use_PrivateKey_ASN1(EVP_PKEY_RSA, www_context,
>> cbin, len)) {
>>              ERR_error_string(ERR_get_error(), tmp);
>>              return(NULL);
>>          }
>>
>> THAT loads (the use_PrivateKey_ASN1 call returns zero -- and thus
>> obviously likes what I passed it)
>>
>> There's probably something obvious I'm missing on what I'm doing
>> wrong with the d2i call -- any quick hit pointers welcome....
>>
>> -- 
>> Karl Denninger
>> karl at denninger.net <mailto:karl at denninger.net>
>> /The Market Ticker/
>> /[S/MIME encrypted email preferred]/
>>
>>
> Ok, never mind, it appears to take the key but then when I check for
> coherence between the key and certificate it says they don't
> match..... so apparently it does NOT like the key load in ASN1, even
> though it doesn't complain about it when I call the "use" function.
>
> Hmmmm....
>
Maybe I'm onto something here....

If I take a PEM-encoded RSA private key file and convert it to binary
(using b64decode) what I get is not the same thing as I get from
"openssl rsa -inform pem -in key -outform der -out key.der".

But.... I thought from the previous discussion a PEM file was simply a
base64 rendition of the binary in a DER file....  Doesn't look that way.

So what does d2i_AutoPrivateKey actually want as input?  The straight-up
encoded key (out of the "key" file -- that is, read into a memory buffer
the entire thing including the barrier lines, and pass it THAT), just
the base64 encoded part (which I tried, and fails), or??  And what do
the ASN1 format calls to set certs and keys want?  I assume THAT wants
the DER file (binary), but I thought a PEM Base64 component, converted
to binary, WAS a DER file?  What I see here is that they're not the same.

This is pretty-clearly where I'm going wrong; I assume I can ASN1-load
the DER files from the previous, but I'd much prefer to be able to parse
.PEM files instead (since they're human readable) and somewhere I've
gone wrong with that one

What did I miss? :-)

-- 
Karl Denninger
karl at denninger.net <mailto:karl at denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171228/2e0dc849/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4897 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171228/2e0dc849/attachment.bin>