Certificate variables

Legacy Scale
1

Hi,

I’m trying to create a java keystore from a stored certificate variable, inspired by https://octopus.com/blog/wildfly-https

Two differences

  1. my certificates will have only public keys, so I chose to export as the default - a DER encoded binary X.509 (.CER)
  2. I wish to avoid installing open-ssl on our servers (either the Octopus server or deployment target servers) - so wish to “re-hydrate” the certificate in it’s original form and import this into a keystore (not build another certificate as does the blog post)

I imported the certificate, and can export the certificate, however I am trying to “dump” it in a powershell script step using the following line
set-content $OctopusParameters[“dummy.Certificate”] -path c:\dummy.cer -encoding Byte

This fails with the error, set-content : Cannot proceed with byte encoding. When using byte encoding the content must be of type byte.

When I view the certificate in notepad++ it’s definitely a binary file.
When I export the certificate in original, and in binary form (DER - Binary DER encoded.), it’s the same as the file I uploaded (binary compare is identical). The first bytes of the file are “30 82 05” - checking here https://en.wikipedia.org/wiki/List_of_file_signatures - suggests this is a “DER encoded x.509 certificate”

I don’t know that much about encoding ? Can you tell me how to match the format I import the certificate with, with the required output encoding ?

Or is this just something to do with using Octopus variables in powershell and I need to convert it back from some kind of string to binary again - something like

$decoded = [System.Convert]::FromBase64CharArray($e, 0, $e.Length)
$decoded | Set-Content dummy.cer -Encoding Byte

Help appreciated !

CertExport.png

2

Additionally:
If I use no encoding (default encoding on set-content), or ascii encoding on the set-content call I get the same output produced. (So no switch seems to encode it as ascii)

When I do that, and try and import the certificate I get
keytool error: java.lang.Exception: Input not an X.509 certificate

When I try and upload as base 64, and set-content with no flag (default encoding) I get the same error. When I compare the original base 64 encoded certificate and what I exported these are close, but not identical (see attached screenshot) CertExportBase64 (had to zip it)

When I try and upload as base 64, and use the RawOriginal property instead of the Certificate property these files are significantly different. And when I try and use RawOriginal, and encoding byte, I run into the original issue - content is not of type byte

CertExportBase64.7z (15 KB)

3

IN the case above, where I uploaded using the base64 encoded certificate (DER, then export using the Certificate property, with default encoding the differences i see are

  • No header and footer
  • 0D 0A line breaks removed.

I could manually insert these back in i think (if the Octopus variable is presented)

4

ok,

I finally got this working by dumping all the variables, inspecting each property of the certificate variable and using CertificatePem. This created file then matched what I had exported (and Imported into Octopus - a base64 encoded DER)

Since I have a workaround this can go down the priority list but I still have questions !

Any tips on understanding why you expose CertificatePem as the same content as the base64 encoded DER. Are these in fact the same thing ?

Partially answering my own question Reading here


".der A way to encode ASN.1 syntax in binary, a .pem file is just a Base64 encoded .der file. " I can now understand how they might be the same, but then now I don’t understand why RawOriginal is not exactly the same ?

I still don’t understand IF i can upload a certificate in binary format (or if I’ll need to ensure I convert everything before uploading) ??

5

Hi Al,

I’m glad to hear you eventually had a successful outcome. I’m sorry it wasn’t all plain sailing.

I’m not sure if you saw our certificate variables documentation?
After reading your adventure, I’ll see if I can add some tips to it.

I think there are a couple of (understandable) points of confusion:

DER vs PEM
DER and PEM are not exactly the same. DER is a binary format. PEM is the base64 encoded DER, with some headers and footers added.
DER files will also never contain a private-key, whereas PEM files can.

Base64
It seems the base64 encoding has caused some confusion here too.
Octopus variables are always represented as strings, so any binary data is base64 encoded.

The RawOriginal variable contains the exact bytes that were uploaded, base64 encoded. This makes sense when the original file was a PFX or a DER, because these are binary files. It makes less sense when the original file was a PEM, which is a text file.

In the case that the uploaded file was a PEM, RawOriginal still contains the base64 encoded bytes. This can be decoded using something like:

[System.Text.Encoding]::ASCII.GetString([System.Convert]::FromBase64String($OctopusParameters["YourCert.RawOriginal"]))

Alternatively you can access the .CertificatePem variable. The only difference is that the .CertificatePem will not contain the private-key, even if your original file contained one.

You could certainly argue that in the case of PEM, RawOriginal should simply contain the original text. On the one hand it is nice to have it consistent across formats. On the other, I can see how this was unexpected in this case.

I still don’t understand IF i can upload a certificate in binary format (or if I’ll need to ensure I convert everything before uploading) ??

You can certainly upload certificates in binary formats. You can upload PFX, DER, or PEM files.

The variables were designed to make it access the certificate in your scripts, in whichever format is most convenient.

I hope this helps. If you have any other questions, or anything is not clear, don’t hesitate to ask.

Regards,
Michael

6

Michael,

Thanks very much for the reply. It’s chewy. I’m digesting it slowly :slight_smile:

In the first screenshot I attached, showing the export wizard you can export the X.509 as DER encoded or base 64 encoded. I confused the latter with a PEM format. That was probably the first part of the confusion. For anyone else searching, your answer, and the information here (which I should have studied harder) should ensure they don’t stumble around like i did !

https://www.feistyduck.com/library/openssl-cookbook/online/ch-openssl.html#openssl-key-and-certificate-conversion