Question as to best options....

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Question as to best options....

Karl Denninger

So let's assume I have system A and B.

System A has some store of certificates and keys.  We'll assume they're in either PEM or DER format and OpenSSL generated them.

System B is going to get passed one or both via a mechanism (e.g. over a TLS connection that it has validated as being "ok" with appropriate cipher and certificate chase, so it's reasonably convinced it's talking to who it thinks it is), and then wishes to install them into executing software so OpenSSL can use them for THAT system to do something with (e.g. take connections from a third machine, sign objects, etc.)  I already know how do the "do something" part with OpenSSL.  System B does *NOT* want to store these persistently on the disk somewhere (even transiently.)

What I'm trying to figure out is the "best" way to handle this.  SSL_CTX_use_PrivateKey accepts a EVP_PKEY pointer, SSL_CTX_use_PrivateKey_ASN1 takes an ASN1 structure of length len, but what is parameter "pk" (not explained in the man page) and this assumes I have an ASN.1.....

I would assume that doing wonky things with EVP_PKEY (like digging into the structure once loaded, grabbing it and transmitting it) is a severely bad idea as the structure may change (e.g. EVP_PKEY is intended to be an opaque structure from a user code perspective.)

So that leaves the obvious question as "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.)

TIA
--
Karl Denninger[hidden email]

The Market Ticker
[S/MIME encrypted email preferred]

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Question as to best options....

OpenSSL - User mailing list

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?

> "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. …


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Question as to best options....

Kurt Roeckx
In reply to this post by Karl Denninger
On Tue, Dec 26, 2017 at 12:38:32PM -0600, Karl Denninger wrote:
>
> What I'm trying to figure out is the "best" way to handle this. 
> SSL_CTX_use_PrivateKey accepts a EVP_PKEY pointer,
> SSL_CTX_use_PrivateKey_ASN1 takes an ASN1 structure of length len, but
> what is parameter "pk" (not explained in the man page) and this assumes
> I have an ASN.1.....

I assume you send the file in DER or PEM format over the SSL
connection. You then probably want to use d2i_PrivateKey() or
d2i_AutoPrivateKey() to turn that into an EVP_PKEY.


Kurt

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Question as to best options....

Karl Denninger
In reply to this post by OpenSSL - User mailing list

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.

> "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)
int SSL_CTX_use_PrivateKey_ASN1(int pk, SSL_CTX *ctx, unsigned char *d, long len);
And likewise, I can just bytewise load a DER file (e.g. read() it into a memory buffer) and then pass that as it's simply a binary copy of the Base64 contained within the markers (plus the EC parameters if it's an ECDSA key)?

If so that makes it materially easier than I thought it would be....

--
Karl Denninger
[hidden email]
The Market Ticker
[S/MIME encrypted email preferred]

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Question as to best options....

Kurt Roeckx
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

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Question as to best options....

Karl Denninger

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
Thanks - I suspect I have enough to get things rolling :-)

--
Karl Denninger
[hidden email]
The Market Ticker
[S/MIME encrypted email preferred]

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Question as to best options....

Karl Denninger
In reply to this post by Kurt Roeckx
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
[hidden email]
The Market Ticker
[S/MIME encrypted email preferred]

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Question as to best options....

Karl Denninger
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
[hidden email]
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....

--
Karl Denninger
[hidden email]
The Market Ticker
[S/MIME encrypted email preferred]

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Question as to best options....

Karl Denninger
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
[hidden email]
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
[hidden email]
The Market Ticker
[S/MIME encrypted email preferred]

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Question as to best options....

OpenSSL - User mailing list

It is hard to follow this thread with all the indenting.

 

>  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".

How do you convert it?  Did you strip off the ---BEGIN and END tags?  Then it absolutely should have been the same thing.

An internal structure, such as an RSA object, can be converted to DER using d2i_RSA.  DER is useful because it is a “flat” format, whereas the internal object is useful in the C code.  Make sense?  DER files are useful if you already know what the filetype is.  The d2i_ and i2d_ functions convert between internal (C structures, with pointers etc) to DER encoding.  They basically work on buffers, only.

PEM files are base64 encoded DER, with BEGIN and END tags that specify what the middle-part is.  It is useful because it is human readable. Also the PEM_read_xxxx functions will check what is expected to what the file says it is.

Most objects have PEM_read and PEM_write functions as well.  They are not necessarily obvious from scanning the header files, because they are declared and implemented as macro’s, as it’s common code with just a pointer to an internal description of what the ASN1/DER looks like.

The documentation on the master branch does a much better, and more complete, job of explaining this.

The function I think you want is PEM_read_PrivateKey.

 

 


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Question as to best options....

Karl Denninger

On 12/28/2017 18:31, Salz, Rich via openssl-users wrote:

It is hard to follow this thread with all the indenting.

 

>  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".

How do you convert it?  Did you strip off the ---BEGIN and END tags?  Then it absolutely should have been the same thing.

Yes, I certainly did.  And it's not the same thing.

Proof:

root@Test-MCP:/usr/local/etc/HD-MCP/ssl/x # diff key.pem test.key
0a1
> -----BEGIN PRIVATE KEY-----
26a28
> -----END PRIVATE KEY-----
root@Test-MCP:/usr/local/etc/HD-MCP/ssl/x # ls -al
total 16
drwxr-xr-x  2 root   wheel   512 Dec 28 18:36 .
drwx------  3 hdmcp  wheel   512 Dec 28 18:33 ..
-rw-------  1 root   wheel  1654 Dec 28 18:33 key.pem
-rw-------  1 root   wheel  1708 Dec 28 18:35 test.key

Only difference is the barrier lines in the test.key file (which have to be there for openssl or it throws up.)  Now we run:

root@Test-MCP:/usr/local/etc/HD-MCP/ssl/x # openssl rsa -inform pem -in test.key -outform der -out key.der
writing RSA key
root@Test-MCP:/usr/local/etc/HD-MCP/ssl/x # b64decode -r key.pem > key.bin     
root@Test-MCP:/usr/local/etc/HD-MCP/ssl/x # ls -la
total 24
drwxr-xr-x  2 root   wheel   512 Dec 28 18:37 .
drwx------  3 hdmcp  wheel   512 Dec 28 18:33 ..
-rw-r--r--  1 root   wheel  1219 Dec 28 18:37 key.bin
-rw-r--r--  1 root   wheel  1193 Dec 28 18:37 key.der
-rw-------  1 root   wheel  1654 Dec 28 18:33 key.pem
-rw-------  1 root   wheel  1708 Dec 28 18:35 test.key
root@Test-MCP:/usr/local/etc/HD-MCP/ssl/x #

Those output files (key.bin and key.der) are not the same -- they're different within the first few bytes on examination with od -t x1, not just on length (e.g. trash at the end)

If I load key.der into a binary buffer and run d2i_AutoPrivateKey against it I get a valid EVP_PKEY buffer back and no error.

I'll chase this down further, but I think the easiest way may be to just run DER files, since those work... :-)

An internal structure, such as an RSA object, can be converted to DER using d2i_RSA.  DER is useful because it is a “flat” format, whereas the internal object is useful in the C code.  Make sense?  DER files are useful if you already know what the filetype is.  The d2i_ and i2d_ functions convert between internal (C structures, with pointers etc) to DER encoding.  They basically work on buffers, only.


PEM files are base64 encoded DER, with BEGIN and END tags that specify what the middle-part is.  It is useful because it is human readable. Also the PEM_read_xxxx functions will check what is expected to what the file says it is.

Most objects have PEM_read and PEM_write functions as well.  They are not necessarily obvious from scanning the header files, because they are declared and implemented as macro’s, as it’s common code with just a pointer to an internal description of what the ASN1/DER looks like.

The documentation on the master branch does a much better, and more complete, job of explaining this.

The function I think you want is PEM_read_PrivateKey.

I'll look in there; my assumption was that I could trivially convert a PEM file into an internal DER representation by stripping the flag lines from the front and rear and then decoding the base64 piece.....

Thanks; I'll figger it out :-)

--
Karl Denninger
[hidden email]
The Market Ticker
[S/MIME encrypted email preferred]

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Question as to best options....

OpenSSL - User mailing list

The difference is “auto private key” versus “RSA private key.”

 

> -----BEGIN PRIVATE KEY-----

This is a private key wrapped in a PKCS8 container with a key-type identifier.

 


root@Test-MCP:/usr/local/etc/HD-MCP/ssl/x # openssl rsa -inform pem -in test.key -outform der -out key.der
writing RSA key

 

This just writes the DER of the RSA key.  Different thing.

 

Try dumping the der files with asn1dump

 

 


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users