OpenSSL: PEM routines:PEM_read_bio:no start line:pem_lib.c:703:Expecting: TRUSTED CERTIFICATE
Categories:
Resolving 'PEM routines:PEM_read_bio:no start line' in OpenSSL on Windows

This article provides a comprehensive guide to troubleshoot and resolve the common OpenSSL error 'PEM routines:PEM_read_bio:no start line:pem_lib.c:703:Expecting: TRUSTED CERTIFICATE', particularly prevalent on Windows systems.
The error message PEM routines:PEM_read_bio:no start line:pem_lib.c:703:Expecting: TRUSTED CERTIFICATE
is a frequent stumbling block for developers and system administrators working with OpenSSL, especially when dealing with certificates on Windows. This error indicates that OpenSSL failed to parse a PEM-encoded file because it couldn't find the expected 'start line' marker, such as -----BEGIN CERTIFICATE-----
or -----BEGIN TRUSTED CERTIFICATE-----
. This usually points to issues with the certificate file's format, content, or encoding.
Understanding the PEM Format and Error Cause
PEM (Privacy-Enhanced Mail) is a common format for storing cryptographic keys and certificates. It's essentially a Base64 encoded block of binary data, wrapped with specific header and footer lines. The 'no start line' error means OpenSSL scanned the file but didn't find the -----BEGIN...-----
marker it was looking for. This can happen for several reasons:
flowchart TD A[OpenSSL Attempts to Read PEM File] --> B{File Content Scanned} B --> C{Is '-----BEGIN...' Found?} C -- No --> D[Error: 'no start line'] D --> E[Common Causes: Incorrect Header/Footer, Extra Characters, Wrong Encoding, Empty File] C -- Yes --> F{Is '-----END...' Found?} F -- No --> G[Error: Malformed PEM (less common for 'no start line')] F -- Yes --> H[PEM Parsed Successfully]
Flowchart illustrating the OpenSSL PEM parsing process and potential error points.
Common causes include:
- Missing or Incorrect Headers/Footers: The
-----BEGIN...-----
and-----END...-----
lines are crucial. Even a single typo or missing dash will cause this error. - Extra Characters: Hidden characters, whitespace, or non-printable characters before or after the BEGIN/END lines, or even within the Base64 block, can corrupt the file.
- Incorrect File Encoding: While PEM is text-based, saving it with an encoding like UTF-16 instead of UTF-8 or ASCII can introduce byte order marks (BOMs) or other issues that OpenSSL cannot handle.
- Empty or Corrupted File: The file might be empty, truncated, or contain completely unrelated binary data.
- Wrong File Type: Attempting to load a DER-encoded certificate (binary) as a PEM-encoded one will also result in this error.
Troubleshooting Steps and Solutions
To resolve this error, systematically check your certificate file for the common issues identified above. The following steps will guide you through the process.
1. Verify PEM Header and Footer Lines
Open the certificate file (.pem
, .crt
, .key
) in a plain text editor (like Notepad++, VS Code, Sublime Text, or even Notepad on Windows). Ensure that the file starts with -----BEGIN CERTIFICATE-----
(or -----BEGIN TRUSTED CERTIFICATE-----
, -----BEGIN RSA PRIVATE KEY-----
, etc., depending on the file's content) and ends with -----END CERTIFICATE-----
(or corresponding end tag). These lines must be exact, including the five hyphens on each side.
2. Check for Extra Characters or Whitespace
Carefully inspect the lines immediately before and after the BEGIN/END markers, and the lines containing the Base64 data. Look for any leading/trailing spaces, blank lines, or invisible characters. Sometimes, copying and pasting from a web page or email client can introduce these. Ensure there are no characters outside the BEGIN/END block. Some editors can show invisible characters.
3. Confirm File Encoding
Ensure the file is saved with a standard text encoding like UTF-8 (without BOM) or ASCII. On Windows, Notepad often defaults to UTF-8 with BOM, which can cause issues. When saving in Notepad, select 'UTF-8' from the 'Encoding' dropdown in the 'Save As' dialog, but be aware that Notepad's 'UTF-8' often includes a BOM. For best results, use a more advanced text editor that allows explicit selection of 'UTF-8 without BOM' or 'ASCII'.
4. Validate Base64 Content
The content between the BEGIN and END lines must be valid Base64 encoded data. It should only contain alphanumeric characters, +
, /
, and =
(padding character). Any other characters indicate corruption. Each line of the Base64 block is typically 64 characters long, though the last line might be shorter.
5. Use OpenSSL to Verify (if possible)
If you have other certificates that work, try to use OpenSSL's x509
command to verify the problematic file. This might give a more specific error if the issue is within the Base64 data itself. For example: openssl x509 -in your_certificate.crt -text -noout
. If this command also fails with the 'no start line' error, it confirms the file format issue.
6. Re-download or Re-generate the Certificate
If all else fails, the certificate file might be fundamentally corrupted. Try re-downloading it from its source (e.g., your CA, server, or certificate provider) or re-generating it if you have the means.
Example of a Correctly Formatted PEM Certificate
A correctly formatted PEM certificate should look similar to this. Pay close attention to the exact syntax of the BEGIN and END lines, and the structure of the Base64 encoded data.
-----BEGIN CERTIFICATE-----
MIIDrzCCApWgAwIBAgIQAPX+k/y/y/y/y/y/y/y/y/y/y/y/y/y/y/y/y/y/y/y
... (many lines of Base64 encoded data) ...
+y/y/y/y/y/y/y/y/y/y/y/y/y/y/y/y/y/y/y/y/y/y/y/y/y/y/y/y/y/y/y/y
-----END CERTIFICATE-----
Example of a correctly formatted PEM certificate file.