SSL certificate (PEM/CRT) information analysis/validity decoder | ZeroTools

Digital certificates used in SSL/TLS are generally distributed in the PEM (Privacy-Enhanced Mail) format, which is a Base64 encoding of the binary DER (Distinguished Encoding Rules) format, with headers and footers added before and after.

The decoding process of this tool begins with reading this PEM-formatted text data within the browser and visualizing its internal information.

As an operation, you can either directly paste the string into the text area on the screen or drop or select a file with an extension such as .crt, .pem, or .cer to input the PEM text.

Because there is no strict character length or file size limit enforced, it is recommended to verify functionality using small, non-confidential certificate examples.

If the input text lacks the -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- markers, the tool will automatically wrap the entire raw string in a certificate block to attempt parsing.

In accordance with the standard node-forge specification, the tool inspects and processes only the first PEM block provided within the input payload.

If the leading block happens to be a private key or a Certificate Signing Request (CSR), the parsing operation may fail immediately without continuing to search for subsequent certificate blocks that might follow.

For the core certificate parsing functionality, the tool dynamically loads the node-forge library (version 1.4.0) via an external CDN (jsDelivr), so browser-level network communication occurs during initial script retrieval and operation.

The most fundamental information in a certificate is the Distinguished Name, which defines to whom it was issued (Subject) and which Certificate Authority issued it (Issuer).

The tool analyzes the internal ASN.1 structure, extracts these attributes, and expands them into a table on the screen.

The items displayed include Common Name (CN), Organization (O), Organizational Unit (OU), Country (C), State/Province (ST), Locality (L), and email address, and the extracted values are output as formatted text strings.

In scenarios where multiple values are defined for a single attribute—such as when the same distinguished name OID or relative distinguished name element appears multiple times within the Subject or Issuer fields—the tool preserves repeated attribute values in encounter order joined by ' / ' rather than overwriting prior entries.

Note that this display provides a sequential overview rather than a lossless hierarchical ASN.1 DN tree representation, any unrecognized or unknown attribute labels simply remain displayed as their raw keys, and the output does not perform legal identity validation or certificate authorization checks.

Furthermore, in addition to these distinguished name details, the decoding result of the SerialNumber, which identifies the certificate within the issuer's scope, is displayed in a separate frame.

Since the serial number is often a very long hexadecimal string, we provide an operation that can be acquired to the clipboard with a single click using the copy button, which not only reduces the burden of visual confirmation.

This plays a role in assisting the work of verifying the identification information of the certificate at hand and the work of recording it in the certificate management ledger for the update timing.

X.509 certificates contain "Not Before" and "Not After" data that define the period during which the certificate is treated as valid.

The decoding engine retrieves the Coordinated Universal Time (UTC) based date data from these fields and converts it into an intuitive year, month, and day date string according to the time zone and time format set on the viewing device using the tool, and displays it on the screen.

In the validity period determination process, the time stamps of the acquired start date and expiration date are compared with the local time of the device (the current time acquired by the web browser) at the exact moment the decode operation is executed.

If the device time falls within the specified period at the time of decoding, a valid status is displayed at the top of the screen with a green icon, and the remaining days from the current time to the expiration date are calculated and shown.

If it is outside the period, a red warning icon is displayed to alert the user, and the remaining days may simply reflect 0. Changing PEM text, choosing another file, loading a sample, or clearing input immediately removes the previous parsed report, and the user must press Parse after entering text or loading a file to generate a new report, with no automatic validity or trust verification performed.

The point to note here is the fact that this status display is merely based on a simple comparison of dates and times locally. This tool does not verify the construction of a trust chain from a root certificate authority, real-time status confirmation by a revocation list (CRL) or OCSP, or matching with the target host name, which are necessary for the certificate to fulfill its original role.

Since the purpose is to expand the attributes of a single file, verification involving communication is not performed, and it is necessary to read the results on the premise that the status within the period displayed does not guarantee systemic security.

Specifications for public key information and signature algorithms are also decoded from the internal data of the certificate. This tool reads the types of supported public key algorithms and outputs their parameters and bit lengths.

Displaying the key length merely indicates the public key parameters and is completely distinct from evaluating cryptographic strength or determining actual security.

In the current implementation, the tool targets the parsing of public key data for the widely used RSA cryptography. It does not guarantee the successful parsing of all certificates.

If an RSA key is detected, the bit length of its modulus (n) is calculated and reflected on the screen as a specific "key length" such as 2048 bits or 4096 bits.

On the other hand, if a public key based on other newer algorithms such as Elliptic Curve Cryptography (EC/ECDSA) or Ed25519 is input, the certificate parsing itself may result in an error because the library's primary focus in this implementation is RSA.

Please do not assume that it fully supports EC or Ed25519 parsing.

Along with this, the Signature Algorithm identifier used to prove that the certificate data has not been tampered with is also subject to extraction.

The current screen displays the signature algorithm as an OID numeric value, such as 1.2.840.113549.1.1.11, rather than automatically converting it to a human-readable name or verifying the signature's validity.

If necessary, please check against the official definition of the corresponding OID. These cryptography-related data are also processed and converted within the browser's memory space.

Calculating the hash value (fingerprint) required for confirming the identity of a certificate or registering it with various cloud services and APIs is a frequently performed operation in certificate decoding.

This tool calculates two types of fingerprints using the SHA-1 and SHA-256 algorithms and provides them as hexadecimal strings (separated by colons).

Regarding the technical specifications for this calculation process, this implementation calculates cryptographic fingerprints by directly hashing the original DER binary data obtained from decoding the Base64 payload of the input PEM certificate, rather than relying on a reconstructed or re-serialized byte stream.

The resulting SHA-1 and SHA-256 digests are formatted as uppercase hexadecimal pairs separated by colons. However, it should be noted that computing and displaying standalone fingerprint digests serves purely as an integrity and identification aid; it does not perform cryptographic signature validation, certificate chain path discovery, or issuer trust verification.

The generated SHA-1 and SHA-256 strings are displayed in a monospace font area that minimizes the character size, and are stored in UI components that can be copied with a single click, similar to the serial number.

Easily copy the certificate's serial number, SHA-256 fingerprint, or SHA-1 fingerprint to your clipboard with immediate confirmation once the operation completes.

If clipboard access is blocked or unavailable in your browser, a manual fallback field appears automatically so you can copy the value with standard keyboard shortcuts.

Any modification to the PEM input or initiating any new decode attempt (including for the same PEM) automatically resets active copy states and clears outdated notices, while newer copy requests supersede prior pending feedback without claiming operating system write cancellation.

Although SHA-1 is currently deprecated for new signature purposes due to security reasons, there are still cases where the value is required for limited purposes such as legacy identifiers or specific cloud services, so it is maintained as a calculation item.

Extended attributes (Extensions) introduced in X.509 v3 are used to finely define the purpose of a certificate or to make it compatible with multiple domains.

In the parsing process of the tool, the data group stored in this extended area is extracted as an array and listed as individual records in the list at the bottom of the screen.

Among them, the one that is checked most frequently is the Subject Alternative Name (SAN) extension. In multi-domain certificates or wildcard certificates, valid hostnames, domain names, and network addresses to be protected are enumerated within this extension area.

In the parsing process, specific SAN entry types are recognized and labeled accordingly: type 1 is displayed as an Email address, type 2 is represented as a DNS name, type 6 is mapped as a URI, and type 7 is presented as an IP address (utilizing the node-forge decoded IP string format whenever available).

Any other unmapped extension types are labeled generically by their numeric identifier, such as typeN. Note that more complex or vendor-specific binary structures within other SAN entries are not fully interpreted or decoded into deep custom schemas, and the parser performs purely informative structural extraction without executing hostname verification or domain validation logic against specific target servers.

For extended attributes other than SAN (such as Key Usage or Basic Constraints), the tool uses the identified name as a label and expands the set value as a string.

If the value has a complex object structure that cannot be expressed as a simple string, it is converted into a JSON string within the program before being output, attempting to display the value.

However, for extensions other than SAN, the strings derived from binary data may be displayed as is, meaning not all items of each extension are expanded in a fully meaningful way.

The extension display clears with other results when input changes, and hostname verification is not performed.