Turn bytes into a labeled text object
01A certificate or key is a structured binary object. Base64 turns its bytes into printable characters; boundary lines identify the kind of structure inside. These wrappers are often called PEM, after Privacy-Enhanced Mail, but this RFC defines its own textual encoding.
A schematic CERTIFICATE wrapper names the expected inner type. Its placeholder body is not a usable certificate; a real file must contain the required encoded Certificate structure.
Source for this drawing: RFC 7468 · Read RFC section 2 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
A text wrapper changes how bytes travel, not what they mean.
- The opening line is five hyphens, BEGIN, one space, the label and five hyphens. The closing line uses END in the same form. Labels are case-sensitive; generators MUST use matching opening and closing labels.
- The body uses the ordinary Base64 alphabet from RFC 4648 §4, including + and / and any required = padding. It is not the URL-safe alphabet.
- ASN.1 (Abstract Syntax Notation One) describes the inner structures. BER (Basic Encoding Rules) encodes them as bytes; DER (Distinguished Encoding Rules) restricts BER to a canonical representation. Textual decoding alone does not check those structures.
The two-byte 00 ff → AP8= example only illustrates Base64. It is deliberately NOT a certificate or key. No real private material is used.
Read the RFC section ↗