CSR Template Specification/Format

[tedheying]

What is the specification necessary for me to create a template for my company "Honeywell, Inc, etc", needed for the following byte array which was used in the example in atcatls_tests.c /////////////////////////////////////////////////////////////////////////////////////// // CSR Structures

uint8_t g_DeviceCsr[] = { 0x30, 0x82, 0x01, 0x35, 0x30, 0x81, 0xDC, 0x02, 0x01, 0x00, 0x30, 0x7A, 0x31, 0x0B, 0x30, 0x09, 0x06, 0x03, 0x55, 0x04, 0x06, 0x13, 0x02, 0x55, 0x53, 0x31, 0x11, 0x30, 0x0F, 0x06, 0x03, 0x55, 0x04, 0x08, 0x0C, 0x08, 0x43, 0x6F, 0x6C, 0x6F, 0x72, 0x61, 0x64, 0x6F, 0x31, 0x19, 0x30, 0x17, 0x06, 0x03, 0x55, 0x04, 0x07, 0x0C, 0x10, 0x43, 0x6F, 0x6C, 0x6F, 0x72, 0x61, 0x64, 0x6F, 0x20, 0x53, 0x70, 0x72, 0x69, 0x6E, 0x67, 0x73, 0x31, 0x0E, 0x30, 0x0C, 0x06, 0x03, 0x55, 0x04, 0x0A, 0x0C, 0x05, 0x41, 0x74, 0x6D, 0x65, 0x6C, 0x31, 0x18, 0x30, 0x16, 0x06, 0x03, 0x55, 0x04, 0x0B, 0x0C, 0x0F, 0x53, 0x65, 0x63, 0x75, 0x72, 0x65, 0x20, 0x50, 0x72, 0x6F, 0x64, 0x75, 0x63, 0x74, 0x73, 0x31, 0x13, 0x30, 0x11, 0x06, 0x03, 0x55, 0x04, 0x03, 0x0C, 0x0A, 0x41, 0x57, 0x53, 0x20, 0x44, 0x65, 0x76, 0x69, 0x63, 0x65, 0x30, 0x59, 0x30, 0x13, 0x06, 0x07, 0x2A, 0x86, 0x48, 0xCE, 0x3D, 0x02, 0x01, 0x06, 0x08, 0x2A, 0x86, 0x48, 0xCE, 0x3D, 0x03, 0x01, 0x07, 0x03, 0x42, 0x00, 0x04, 0x68, 0x94, 0x9A, 0x24, 0x35, 0xCB, 0xE5, 0x98, 0x3A, 0x35, 0x16, 0xDA, 0x7A, 0x0B, 0x61, 0x75, 0x8A, 0x63, 0x21, 0xEF, 0x50, 0xE1, 0x54, 0x45, 0x24, 0x11, 0x0D, 0x10, 0xA0, 0x53, 0x1B, 0x5F, 0x6F, 0x50, 0x0D, 0xBF, 0xBA, 0x0D, 0x01, 0xFA, 0x20, 0x01, 0x4D, 0x59, 0x92, 0xCE, 0xF9, 0x3F, 0xBB, 0xD2, 0x3D, 0xAA, 0x9A, 0x48, 0xAA, 0x98, 0x6A, 0xDC, 0x3C, 0xC8, 0x97, 0xD3, 0xDD, 0xAC, 0xA0, 0x00, 0x30, 0x0A, 0x06, 0x08, 0x2A, 0x86, 0x48, 0xCE, 0x3D, 0x04, 0x03, 0x02, 0x03, 0x48, 0x00, 0x30, 0x45, 0x02, 0x21, 0x00, 0xB8, 0x01, 0x0D, 0xF0, 0xF9, 0x86, 0xD9, 0x33, 0xB6, 0x03, 0x7C, 0x72, 0x50, 0x64, 0x67, 0x53, 0x77, 0x51, 0x1F, 0xE1, 0x1A, 0x16, 0xEB, 0xFE, 0xD6, 0x3C, 0x9D, 0xEC, 0x05, 0x35, 0xE5, 0xDD, 0x02, 0x20, 0x70, 0x96, 0x1E, 0x4C, 0x5F, 0xB6, 0x0E, 0xE2, 0x28, 0xB8, 0x8D, 0x6C, 0xE4, 0x02, 0x63, 0x15, 0x79, 0x7C, 0x6A, 0x29, 0x3F, 0x7E, 0xEB, 0x48, 0x0F, 0x8F, 0x41, 0x15, 0x92, 0x4B, 0xF4, 0xB5 };

[agostrer]

I must admit: it is not too user-friendly.

I use the following procedure:

openssl ecparam -out privkeys/template.key -name prime256v1 -genkey openssl req -new -key privkeys/emplate.key -out csr/template.csr -outform DER -sha256 -config openssl.cnf -subj "/C=US/ST=CA/O=Honeywell/CN=webclient/" -verify

ls -ltr csr/template.csr xxd -i csr/template.csr

Copy result into g_DeviceCsr array Then adjust offsets in the g_DeviceCsrDef structure: they most likely will be different.

Regards, Alex.

On Wed, Jun 27, 2018 at 8:03 AM, tedheying notifications@github.com wrote:

What is the specification necessary for me to create a template for my company "Honeywell, Inc, etc", needed for the following byte array which was used in the example in atcatls_tests.c //////////////////////////////////////////////////////////// /////////////////////////// // CSR Structures

uint8_t g_DeviceCsr[] = { 0x30, 0x82, 0x01, 0x35, 0x30, 0x81, 0xDC, 0x02, 0x01, 0x00, 0x30, 0x7A, 0x31, 0x0B, 0x30, 0x09, 0x06, 0x03, 0x55, 0x04, 0x06, 0x13, 0x02, 0x55, 0x53, 0x31, 0x11, 0x30, 0x0F, 0x06, 0x03, 0x55, 0x04, 0x08, 0x0C, 0x08, 0x43, 0x6F, 0x6C, 0x6F, 0x72, 0x61, 0x64, 0x6F, 0x31, 0x19, 0x30, 0x17, 0x06, 0x03, 0x55, 0x04, 0x07, 0x0C, 0x10, 0x43, 0x6F, 0x6C, 0x6F, 0x72, 0x61, 0x64, 0x6F, 0x20, 0x53, 0x70, 0x72, 0x69, 0x6E, 0x67, 0x73, 0x31, 0x0E, 0x30, 0x0C, 0x06, 0x03, 0x55, 0x04, 0x0A, 0x0C, 0x05, 0x41, 0x74, 0x6D, 0x65, 0x6C, 0x31, 0x18, 0x30, 0x16, 0x06, 0x03, 0x55, 0x04, 0x0B, 0x0C, 0x0F, 0x53, 0x65, 0x63, 0x75, 0x72, 0x65, 0x20, 0x50, 0x72, 0x6F, 0x64, 0x75, 0x63, 0x74, 0x73, 0x31, 0x13, 0x30, 0x11, 0x06, 0x03, 0x55, 0x04, 0x03, 0x0C, 0x0A, 0x41, 0x57, 0x53, 0x20, 0x44, 0x65, 0x76, 0x69, 0x63, 0x65, 0x30, 0x59, 0x30, 0x13, 0x06, 0x07, 0x2A, 0x86, 0x48, 0xCE, 0x3D, 0x02, 0x01, 0x06, 0x08, 0x2A, 0x86, 0x48, 0xCE, 0x3D, 0x03, 0x01, 0x07, 0x03, 0x42, 0x00, 0x04, 0x68, 0x94, 0x9A, 0x24, 0x35, 0xCB, 0xE5, 0x98, 0x3A, 0x35, 0x16, 0xDA, 0x7A, 0x0B, 0x61, 0x75, 0x8A, 0x63, 0x21, 0xEF, 0x50, 0xE1, 0x54, 0x45, 0x24, 0x11, 0x0D, 0x10, 0xA0, 0x53, 0x1B, 0x5F, 0x6F, 0x50, 0x0D, 0xBF, 0xBA, 0x0D, 0x01, 0xFA, 0x20, 0x01, 0x4D, 0x59, 0x92, 0xCE, 0xF9, 0x3F, 0xBB, 0xD2, 0x3D, 0xAA, 0x9A, 0x48, 0xAA, 0x98, 0x6A, 0xDC, 0x3C, 0xC8, 0x97, 0xD3, 0xDD, 0xAC, 0xA0, 0x00, 0x30, 0x0A, 0x06, 0x08, 0x2A, 0x86, 0x48, 0xCE, 0x3D, 0x04, 0x03, 0x02, 0x03, 0x48, 0x00, 0x30, 0x45, 0x02, 0x21, 0x00, 0xB8, 0x01, 0x0D, 0xF0, 0xF9, 0x86, 0xD9, 0x33, 0xB6, 0x03, 0x7C, 0x72, 0x50, 0x64, 0x67, 0x53, 0x77, 0x51, 0x1F, 0xE1, 0x1A, 0x16, 0xEB, 0xFE, 0xD6, 0x3C, 0x9D, 0xEC, 0x05, 0x35, 0xE5, 0xDD, 0x02, 0x20, 0x70, 0x96, 0x1E, 0x4C, 0x5F, 0xB6, 0x0E, 0xE2, 0x28, 0xB8, 0x8D, 0x6C, 0xE4, 0x02, 0x63, 0x15, 0x79, 0x7C, 0x6A, 0x29, 0x3F, 0x7E, 0xEB, 0x48, 0x0F, 0x8F, 0x41, 0x15, 0x92, 0x4B, 0xF4, 0xB5 };

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/MicrochipTech/cryptoauth-openssl-engine/issues/20, or mute the thread https://github.com/notifications/unsubscribe-auth/AGdnUMoXOig0Zf0LIM5kPlpyxgeMUYxbks5uA562gaJpZM4U54km .

[schielimicrochip]

yes, this is not a very user friendly process. We are working on new tools to make it a lot easier to generate the certificate template. it will first be tested internally for some time until it can be released to the general public. it will likely become available during Q4 2018.. sorry for the inconvenience. Nicolas

[tedheying]

What we need is a solution to get CSR's created for our device. Unfortunately the open ssl patch you packaged w/an older version of the engine was applied on open ssl version 1.0.2.n. We are running 1.0.2.j. We tried to apply the patch but got compile errors. Can you provide us w/a patch that is compatible w/1.0.2.j?

[bryan-hunt]

@tedheying This question was also submitted to microchip support answered. Can you confirm if you're receiving updates from your support request there?

[bryan-hunt]

@agostrer The correct way to perform a CSR using the engine is this way:

The first step is to get the key meta data file: openssl engine ateccx08 -t -post GET_DEVICE_KEY:./key_data.pem

Then the next step is to use that key meta data to generate a csr using openssl: openssl req -new -sha256 -engine ateccx08 -key ./key_data.pem -out ./device.csr

If you have a provisioned part from Microchip the CSR step is unnecessary and you instead extract the cert chain:

openssl engine ateccx08 -t -post GET_DEVICE_CERT:./device.der openssl engine ateccx08 -t -post GET_SIGNER_CERT:./signer.der

Along with the key data file created earlier you can use that in a system that depends on key files. Otherwise the preferred method is to use the engine as a certificate provider (if you're writing your own application). Most older software has not updated their systems to use the certificate provider api.

[tedheying]

Yes I saw it thanks.

On Thu, Jun 28, 2018 at 9:21 AM Bryan Hunt notifications@github.com wrote:

@tedheying https://github.com/tedheying This question was also submitted to microchip support answered. Can you confirm if you're receiving updates from your support request there?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/MicrochipTech/cryptoauth-openssl-engine/issues/20#issuecomment-401032416, or mute the thread https://github.com/notifications/unsubscribe-auth/Ah9jIeXqJzUak5koAl55d1HyXhflCheIks5uBNhvgaJpZM4U54km .

[tedheying]

BTW we are running w/Yocto poky 1.8 Linux distribution, as opposed to Ubuntu, etc.

[tedheying]

We are getting an undefined reference to ECDH_generate_key() which is in crypto/ecdh/ech_key.c. Do you have a recipe for building openssl that you could give us?

[bryan-hunt]

I'm assuming you've tried to apply patches from the previous release into your OpenSSL versions. ECDH_generate_key is defined in one of those patches.

Generally this method has been a maintenance problem so hardware based ECDH & KDF support for TLS session has been deferred to OpenSSL 1.1