Two fingerprints, one 64 characters and one 95 characters
It started with a message in a work group chat. Somebody pasted a certificate fingerprint with colons between the groups, and the string ended with one extra colon; the copy I read out of a local file was one unbroken run of 64 hexadecimal characters. The reflex is to assume one side computed it wrong. Neither did. Three variables sit on top of every fingerprint: which object gets digested, which digest is used, and which display convention the string was written in.
The digest object is the DER of the whole certificate
A fingerprint is a digest over the DER encoding of the entire certificate, not over the public key or the PEM text. The sample certificate decodes to a DER blob of 1159 bytes, and the same certificate wrapped as Base64 PEM is 1627 bytes; feeding the two files in sequence returns three fingerprints identical character for character. The container grows while the digest stays still: a byte order mark gives 1630 bytes, CRLF gives 1654 bytes, trailing whitespace gives 1635 bytes, and squeezing the Base64 body onto one line gives a fourth shape. None of them moves a single character, because each unwraps back to the same DER.
Only bytes inside the DER move a fingerprint. The comparison sample differs by 1 byte, its public key section encodes to the same Base64 text at 392 characters, and yet the SHA-256 fingerprint disagrees on 62 of 64 characters while SHA-1 disagrees on 39 of 40. Taking SHA-256 over that 294 byte public key block alone gives a fourth string matching none of the three fingerprints. A fingerprint names the certificate, not the key inside it.
Three digests, four display forms
The result area prints three fingerprint lines in a fixed order, MD5, SHA-1 and SHA-256, each twice as long as the digest measured in bytes: 32, 40 and 64 hexadecimal characters. Four display forms are switchable, lowercase without colons as the default, uppercase without colons, and the two colon separated versions. Grouping sits on byte boundaries, one byte or two hex characters per group, and the last group is not followed by a colon.
| Digest | Hex characters | Digest bytes | Characters with colons | Byte groups |
|---|---|---|---|---|
| MD5 | 32 | 16 | 47 | 16 |
| SHA-1 | 40 | 20 | 59 | 20 |
| SHA-256 | 64 | 32 | 95 | 32 |
The 95 character string is the 64 hexadecimal characters plus 31 colons, the same SHA-256 digest in a second display convention.
Fig. 1: the green segment is hex characters, the grey segment is the inserted colons.
One file can hold more than one certificate
A 1683 byte .p7b and a 2322 byte PEM wrapping PKCS#7 each hand back 2 certificates; writing the same certificate out 50 times inside one file gives a container of 81350 bytes that returns 50 certificates in one pass, every DER still 1159 bytes with the same three fingerprints. The numbering reports only the order the parser met the entries in, never a role: in that two certificate chain the first entry is 1159 bytes and the second is only 462 bytes.
The days-remaining line only looks at the expiry date
That line subtracts the current moment from the expiry time and rounds to whole days, so a certificate that expired less than 12 hours ago still reads "0 days left" instead of going negative. The start of validity never enters the arithmetic: a certificate whose notBefore sits on 2027-06-01 prints "587 days left". The time lines follow the machine instead of a fixed zone, the same certificate prints 2026-09-01 00:00 when TZ is UTC and 2026-09-01 08:00 when TZ is UTC+8, both suffixed "local time zone", and the days remaining come out as 144 either way.
Three ways to export the public key
The result area also carries a separate public key block. The sample is an RSA-2048 certificate whose public key section is 294 bytes, and the three export forms are: a PEM with the -----BEGIN PUBLIC KEY----- header and footer, 450 characters over 9 lines; a bare Base64 body wrapped every 64 characters, 398 characters over 7 lines; and the same body with no header or footer, 392 characters on 1 line. The SHA-256 taken over that content covers none of the subject, the validity window, the issuer or the signature, so a public key digest never reconciles against a certificate fingerprint.
Key bit length and serial number, two rules
For RSA it reports the real modulus bit length, and both samples lined up, the 2048 one and the 1024 one. Elliptic curve is an estimate: the parser takes the bit string length, subtracts one and multiplies by eight, which is why the P-521 certificate shows "528 bits" while its real length is 521 bits; the curve name is still looked up from the 132 byte encoding and printed as P-521 (secp521r1). The serial number line is a third rule, its display width equals twice the content byte count, the longest sample ran to 42 characters out of 21 content bytes, and leading zeros survive, so 00BFFF is three bytes rather than two.
What can be checked, and what cannot
The four keystore suffixes .p12 / .pfx / .jks / .keystore are refused on the suffix alone, so renaming a valid 1159 byte DER to .p12 earns the same rejection. A file holding only a PRIVATE KEY or a PUBLIC KEY PEM gets an explicit message. A certificate and its private key written into the same 3331 byte file yield only 1 certificate, the key block quietly ignored. Detection reads content and not the extension, the same PEM renamed to cert.txt still parses. Broken input still gets size information: a DER cut in half to 579 bytes is reported as "this certificate declares 1159 bytes but the file holds only 579 bytes".
What this will not do is verify a signature. The certificate with 1 byte changed parses normally, its three fingerprints are computed, all 17 field lines stay readable and not one warning appears. Two matching fingerprints mean only that two files are the same certificate, they say nothing about a complete chain.
Batch input only flows one way
Drop in 3 files where 1 is a 65 byte piece of plain text and the result area shows 2 certificates, while the error line quotes only the first failure reason. Drop in one more afterwards and the same session accumulates to 3 certificates instead of replacing what was already on the board; the only way back to an empty list is the clear-all button. On the output side there is one copy button for the three fingerprint lines and one for the public key block, only the selected certificate is visible at a time, and there is no side by side comparison and no export entry.
Fig. 2: the digest only ever sees the green layer, the 1159 bytes underneath, and the three container layers never touch the fingerprint.
Q: One string is 64 characters and the other is 95, same certificate or not?
The 95 character one is colon grouped, which is 64 hexadecimal characters plus 31 colons. Delete the colons and both strings fall back to one length; if every position then agrees, it is the same certificate.
Q: The string I was sent ends with an extra colon, does it matter?
Colon grouping never ends with a colon, so that trailing one did not come from the tool and was almost certainly added by hand during a copy. Delete it before comparing, or switch both sides to the no-colon form.
Q: All three fingerprints match, so is the chain safe?
No. Matching fingerprints prove only that two files describe the same certificate under the same digest. The certificate with a single byte changed still parsed, still returned three fingerprints and 17 field lines, and still raised no warning.
Q: Same certificate, will PEM and DER give different fingerprints?
They will not. The 1159 byte DER and the 1627 byte PEM returned three fingerprints identical character for character, and a byte order mark, CRLF or Base64 squeezed onto one line stayed identical too.
How the argument ended: both strings were cut to the lowercase no-colon form, both came out at 64 characters, they matched character for character, and the extra tail colon had been added by hand. Every sample file here went through the local parser on the certificate fingerprint page, so the bytes never left the browser, and all four display forms agreed with the openssl commands character for character. When you are not sure a file is a certificate, check its magic number with the file info page first.