While testing file upload functionality in web application, which allows only .cer files, I found out that it is possible to upload a .cer file where at the end of the file, after „-----END CERTIFICATE-----„ it is possible to append data.

Does this mean that the content of the file is not verified correctly, or it is a standard behavior? When I add additional data before „-----END CERTIFICATE-----“ there is an error and I cannot upload the file. Uploading other files like image files with changed extension to .cer is also not possible.

  • it appears that what comes before is verified correctly, but anything after is ignored
    – schroeder
    Dec 1, 2017 at 10:51
  • How exactly are you validating it currently? Also, how are you using said files? Not much for us to say without more details. Dec 1, 2017 at 11:35

1 Answer 1


TLDR: 'PEM' format only uses the part between dashed BEGIN and END lines

The so-called PEM format used by lots of crypto software has evolved somewhat over time and isn't entirely standard. RFC7468 (in 2015) documents and describes some of the variations for some data types, including (X.509/PKIX) certificate. I often call this format PEM-style rather than PEM to emphasize the difference.

The core of the PEM-style format was and is that arbitrary (potentially binary) data is base64 encoded, broken into lines, and surrounded by -----BEGIN x---- and -----END x----- lines where x specifies the type of data. (OpenPGP 'armor' is the same except it also adds a base64 checksum.) In its original application to email, PEM needed to and did allow other data before, after and between PEM block(s). In the more recent adaptations of this format, some software does allow such external data and some does not or not always, but when external data is allowed it never affects the PEM object, which is always only the part between BEGIN and END lines; what the software does when external data is present but not allowed is not standard.

Changing anything in the data between the BEGIN and END lines, in a way that is it still valid base64, does change the represented data. An arbitrary change is likely to produce data that is not valid ASN.1 DER, and thus not any certificate at all. A carefully crafted change, including a malicious one, can produce data that is the valid encoding of some certificate, but generally not a valid certificate. Depending on exactly what validation is done this may or may not be detected.

Some (many?) applications that process certificates also accept the DER/binary representation from a file, but I'd expect a web or GUI application is less likely to because binary data generally can't be cut&pasted correctly. These files contain only smatterings of text and cannot be reliably identified, much less validated, by normal tools like cat or more or a text editor.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .