REQ File Documentation

---

Technical details

Feature	Value
Full name	Certificate Signing Request (PKCS#10)
File extension	.req (also .csr)
MIME type	application/pkcs10
Format type	PKCS#10 certification request, usually PEM (Base64) text; sometimes binary DER
Standard	PKCS#10, published as IETF RFC 2986
Underlying encoding	ASN.1 DER (X.690), Base64-armoured for PEM
Produced by	Microsoft certreq.exe (Windows); OpenSSL cross-platform
Introduced	PKCS#10 dates to the 1990s (RSA Security); RFC 2986 in 2000
Open standard	Yes — PKCS#10 is a public specification
PEM header	-----BEGIN CERTIFICATE REQUEST----- (Windows: -----BEGIN NEW CERTIFICATE REQUEST-----)
DER signature	30 82 (ASN.1 SEQUENCE, definite long form)
Contains	Public key, subject DN, requested attributes, self-signature
Does NOT contain	The private key (kept separately in a .key file)
Secret?	No — safe to send to a CA. Only the private key is sensitive
Signature algorithms	e.g. sha256WithRSAEncryption, ECDSA with SHA-256
Related extensions	.csr, .pem, .key, .cer, .crt, .pfx, .p12, .inf
Specification	rfc-editor.org/rfc/rfc2986

What is a REQ file?

A .req file is a Certificate Signing Request: the standardised message a server operator sends to a Certificate Authority (CA) to obtain an SSL/TLS or other X.509 certificate. Its structure is defined by PKCS#10, RSA Security’s Public-Key Cryptography Standard number 10, which the IETF republished verbatim as RFC 2986 in November 2000. The request bundles the public key you want certified together with the identity it should be issued for, and signs that bundle with the matching private key to prove you hold it.

The extension itself is a Windows convention. Microsoft’s built-in certreq.exe writes its output to server.req, so Windows administrators see .req while OpenSSL and the rest of the Unix world write the identical content to a .csr. The two extensions name the same PKCS#10 object; you can rename one to the other with no conversion. Everything below describes what is actually inside that object, because understanding the ASN.1 layout is what lets you read, verify, and trust a request before you submit it.

PEM armour and the DER body

A .req exists in two encodings of the same data. The common one is PEM: a Base64 rendering wrapped in ASCII delimiter lines. A parser recognises it by the first line, -----BEGIN CERTIFICATE REQUEST----- (or -----BEGIN NEW CERTIFICATE REQUEST----- from certreq), and reads Base64 until the matching -----END----- line. Base64 packs three bytes into four printable characters, so the armoured form is roughly 33% larger than the binary it carries, which is the price of surviving copy-paste into a CA’s web form and transit through 7-bit e-mail.

Decode that Base64 and you get DER, the Distinguished Encoding Rules of ASN.1 (ITU-T X.690). DER is a deterministic byte serialisation: every value is a tag byte, a length, and the content. A binary .req is just this DER with the PEM armour stripped, which is why it has no ASCII header and instead opens with the raw bytes 30 82. Tag 0x30 is a SEQUENCE; 0x82 says the length that follows occupies two bytes (definite long form), the usual case because a request carrying a 2048-bit key runs well past the 127-byte short-form limit.

-----BEGIN CERTIFICATE REQUEST-----
MIICijCCAXICAQAwRTELMAkGA1UEBhMCVVMxEzARBgNVBAgMClNvbWUtU3RhdGUx
ITAfBgNVBAoMGEludGVybmV0IFdpZGdpdHMgUHR5IEx0ZDCCASIwDQYJKoZIhvcN
   ... Base64 of the DER CertificationRequest ...
-----END CERTIFICATE REQUEST-----

The CertificationRequest: three top-level fields

Per RFC 2986, the whole file is one ASN.1 CertificationRequest SEQUENCE with exactly three members, in order:

CertificationRequest ::= SEQUENCE {
    certificationRequestInfo  CertificationRequestInfo,
    signatureAlgorithm        AlgorithmIdentifier,
    signature                 BIT STRING
}

The first member, certificationRequestInfo, is the data being requested. The second, signatureAlgorithm, names the algorithm used to sign that data, for example the OID for sha256WithRSAEncryption (1.2.840.113549.1.1.11) or an ECDSA-with-SHA-256 identifier. The third, signature, is a BIT STRING holding the signature computed over the DER encoding of the first member. That ordering matters: the signature covers certificationRequestInfo exactly as it was serialised, so a verifier re-encodes the info block, hashes it, and checks the signature against the public key found inside that same block. The request signs itself.

Inside CertificationRequestInfo: version, subject, key, attributes

The info block is where the request’s meaning lives.

CertificationRequestInfo ::= SEQUENCE {
    version        INTEGER { v1(0) },
    subject        Name,
    subjectPKInfo  SubjectPublicKeyInfo,
    attributes     [0] IMPLICIT Attributes
}

version is the INTEGER 0 for the only version defined. subject is an X.500 Name, a sequence of relative distinguished names that spell out the identity: Common Name (CN, the primary domain such as www.example.com), Organisation (O), Organisational Unit (OU), Locality (L), State (ST) and Country (C). subjectPKInfo is the public key being certified, itself a SEQUENCE of an algorithm identifier plus the encoded key bits; for RSA that is the modulus and exponent, for EC the named curve and the point. Critically, this is the public half only. The private key that pairs with it is never placed in the request.

The attributes field, tagged [0], carries requested extensions. The most important in modern practice is the extensionRequest attribute (PKCS#9 OID 1.2.840.113549.1.9.14), which conveys the Subject Alternative Name list. Since browsers stopped honouring the CN for host matching, the SAN entries are what actually name the domains a certificate will cover, so a multi-domain request lists every host here. Other attributes can request a challenge password or key-usage constraints, though CAs commonly override policy-relevant fields with their own values regardless of what the request asks for.

Self-signing and proof of possession

The signature on a CSR is not there to prove who you are; the CA validates identity separately (domain control, organisation vetting). It exists to demonstrate proof of possession: that whoever assembled the request actually controls the private key matching the public key inside it. The requester hashes the DER of certificationRequestInfo and signs the hash with the private key. Anyone can verify this using only the request itself, because the public key needed to check the signature is embedded in the block that was signed.

This is why a CSR with a mismatched or corrupted key fails validation the moment a CA parses it, before any certificate is issued. It also explains a common operational rule: a CSR is generated from a private key, and if you lose that key you must generate a fresh key pair and a fresh .req. Reusing an old CSR only works while its underlying private key still exists on the server.

What is secret, and what is not

A .req contains only public information: a public key and public identity fields. It is designed to be transmitted to a CA, pasted into an order form, or e-mailed, and none of that exposes anything sensitive. The security-critical file is the separate private key, conventionally a PEM-encoded .key, that was generated alongside the request. That key must never be shared, uploaded, or committed to a repository. If it leaks, any certificate issued for the request can be impersonated, and the correct response is to revoke the certificate and reissue from a new key.

Two practical checks reduce wasted CA round-trips. First, decode and read the request before submitting it, so a typo in the domain or a wrong organisation name is caught early rather than baked into an issued certificate. Second, confirm the SAN list contains every hostname you expect, since a certificate can only cover the names present in the request. Both are one command: openssl req -in server.req -noout -text -verify, which prints the decoded subject, key, and attributes and re-checks the self-signature.

From request to issued certificate

A CSR is an input, not an endpoint. You submit the .req to a public CA or an internal Windows CA; the CA validates the request and its identity claims, then issues a signed X.509 certificate (a .cer or .crt) that binds your public key to the vetted identity. There is no offline conversion that turns a request into a certificate, because only a CA’s signature makes a certificate trustworthy. On Windows the submit-and-retrieve step is certreq -submit server.req cert.cer; elsewhere you upload the PEM text to the CA’s portal and download the issued certificate.

Once the certificate comes back, the request has done its job and is usually discarded. The lasting artefacts are the certificate itself and the private key, which are often bundled together for deployment into a password-protected PFX / PKCS#12 file. The .req is only the opening move: a signed, self-describing statement of “here is a public key, here is the identity I want it certified under, and here is proof I hold the matching private key.”

Frequently asked questions

Is a .req file the same as a .csr file?

Yes. Both are PKCS#10 certification requests with identical internal structure. Windows’ certreq names its output .req; OpenSSL and Unix tools name it .csr. You can rename one to the other, or re-emit it with openssl req -in file.req -out file.csr, and nothing about the content changes.

Why does a binary .req start with the bytes 30 82?

Those are the first bytes of the DER encoding. 0x30 is the ASN.1 tag for a SEQUENCE, and 0x82 signals a two-byte length field (definite long form), which a request needs because its total length exceeds the 127-byte short-form limit once a real public key is included.

References

• IETF RFC 2986 — PKCS #10: Certification Request Syntax Specification v1.7
• Microsoft — certreq command reference
• OpenSSL — openssl req command documentation

Feedback

Was this page helpful?

Yes No

Glad to hear it! Please tell us how we can improve.

Sorry to hear that. Please tell us how we can improve.