nCode & enCoding

Garrett Grimsley

2024-02-18

Programming

nCode Chrome Extension

As mentioned in Playing With Certs, I had found a defunct Google Chrome extension. nCode is an extension that handles various encoding/decoding options, the PEM Certificate decoding being of primary interest.

The Certificate input looks like so:

Certificate Input Screenshot. Shows two text boxes with the top one being input filled with a PEM-formatted certificate for Google.com

It’s straightforward enough: You enter your PEM-encoded certificate, click Decode, and the output field should populate with your certificate details. When I first tried, rather than being greeted by certificate details, I instead saw “undefined.” What was going on here? My certificate was a valid and well-formed, there should be no reason for it to not work. I had to do some digging.

The extension page had a link to the source code on GitHub, and reading through it led me to this snippet:

1
2
3

async function apiCertDecode(input) {
    ...
    response = await axios.post('https://api.ryanallen.ninja/utils/certificate/decode', input).catch(function (error) {

So, nCode is making a call out to the developer’s backend to handle the decode, rather than doing it locally. Had I not found the code on GitHub, I could have reached the same conclusion by using the Inspect Popup functionality to view the Console output and Network traffic generated by nCode.

nCode Console Screenshot. Shows Console page with various errors indicating failed network requests

Note that these screenshots may not be exactly what I saw, but you get the point. I’ve since registered the backend domain and pointed it to my own host, so the errors may have differed prior to then.

nCode Network Screenshot. Shows Network page with failed request to decode endpoint

From this point, I checked to see why the requests were failing, including trying to ping the api.ryanallen.ninja site. Nothing came back, so I checked to see if the domain was registered, and registered it as it was not.

I ended up writing a barebones endpoint on Netlify which gave me HTTPS and 125,000 free function invocations per month.

const handler: Handler = async (event: HandlerEvent, context: HandlerContext) => {
  const cert = new crypto.X509Certificate(event.body);

  const body = {"subject": cert.subject, "san": cert.subjectAltName, "validFrom": cert.validFrom, "validTo": cert.validTo, "serialNumber": cert.serialNumber}
  return {
      headers: {
      "Access-Control-Allow-Origin": "*",
      "Origin": "*"
      },
    statusCode: 200,
    body: JSON.stringify(body)
  };
};

Once that was in place, I gave it a whirl:

nCode Certificate Input Screenshot. Shows two text boxes, with the the top one being input filled with a PEM-formatted certificate for Google.com, and the bottom one being JSON output describing human-readable information about the certificate.

Certificate Encoding & Decoding

I’ve since lost the collection of articles I read while researching how to turn a PEM-encoded certificate into human-readable text, but it should suffice to say that I’m exceptionally grateful that the Crypto module exists. Sticking with the example Google.com certificate, let’s briefly look at what’s going on under the hood.
PEM Encoded Google.com Certificate:

If you don’t recognize the blob of text, it’s base64-encoded data. The == and the end of the blob is one dead giveaway, it is padding as defined in RFC 4648, which establishes the Base64 encoding standard. This is mandated by RFC 7468, which relates to certificate encoding. It says that “The encoded data MUST be a BER…encoded ASN.1 Certificate structure…” which brings us to Abstract Syntax Notation One. Borrowing from Wikipedia, “ASN.1 is a standard interface description language (IDL, think Protobuf or OpenAPI spec) for defining data structures that can be serialized and deserialized in a cross-platform way.”
For our purposes, it means that when we try to run a Base64-decode on the certifacte in Notepad++, we get this:
Screenshot of decoded certificate in text editor showing unreadle text interspersed with readable text
So, what is going on here? Why can’t we read all of the text? Our text editor is treating all of the content as UTF-8 encoded text. There it is again, encoding. In short, the text editor is trying to decode the data according to the UTF-8 specification, rather than the BER encoded ASN.1 Certificate structure, known as X.509. Referring to the X.509 spec, we are going to drill down into lines 8 and 9 of the text 240129080447Z which I suspect are timestamps.

Starting at Basic Certificate Fields, we read the spec like so:

TitleAndName ::= Is Composed Of {
    title       BIT STRING,
    name        Name
}

Name ::= Is Composed Of {
    firstName   BIT STRING,
    lastName    BIT STRING
}

Bit String is an example of a built-in type in ASN.1. You don’t need to remember those. When you read the above example, it should work out like this:

TitleAndName
- Title (Bit String)
- Name
  - firstName (Bit String)
  - lastName (Bit String)

We will exclude irrelevant fields for clarity.

Certificate  ::=  SEQUENCE  {
        tbsCertificate       TBSCertificate
        }

TBSCertificate  ::=  SEQUENCE  {
        validity             Validity
        }

Validity ::= SEQUENCE {
        notBefore      Time,
        notAfter       Time }

Time ::= CHOICE {
        utcTime        UTCTime,
        generalTime    GeneralizedTime }

At this point we have, as it says, a CHOICE between UTCTime and GeneralizedTime. According to the spec, certificate validity dates through the year 2049 must be encoded as UTCTime. Thankfully, UTCTime is built into ASN.1 as such: ‘UTCTime values take the form of either “YYMMDDhhmm[ss]Z” or…’ Z being Zulu time.

So, more legibly(?):

Certificate
- TBSCertificate
  - validity
    - notBefore (UTCTime)
    - notAfter (UTCTime)

1 2	240129080447Z 240422080446Z

translates to:

1 2	notBefore: 2024-01-29 08:04:47Z notAfter: 2024-04-22 08:04:46Z

Returning to nCode, when we decode the certifacte, we see the following:

nCode Screenshot, showing highlighted validFrom and validTo timestamps in Zulu time

All of that and more is possible with little effort on our part thanks to the dozens contributors to the Crypto module of nodejs. Much appreciation to all of them.

In a future post, I’ll go into detail about what exactly these unreadable bits are:

White characters on black background, the result of decoding a different data type

Sources:

Crypto Contributors:

To pull the full list of contributors, run the following commands

1
2
3

git clone https://github.com/nodejs/node.git
cd lib/internal/
git shortlog --numbered --summary crypto

and you should see something like so:

69  Tobias Nießen
68  Filip Skokan
21  James M Snell
20  Antoine du Hamel
15  Daniel Bevenius
15  Ruben Bridgewater