Back to Guides
CertificatesTroubleshooting

Why Your CSR Got Rejected (And How to Fix It)

Your CA bounced your certificate request. Here's what went wrong and how to generate a CSR that actually works.

10-12 min readJanuary 2026
Why your CSR got rejected - common causes and how to fix them
PKI Pro Quick Scan

Already know PKI? Here's the quick reference:

  • Key size - RSA minimum 2048-bit; ECC minimum P-256; RSA-1024 rejected everywhere
  • Weak keys - Debian OpenSSL bug (2006-2008), known compromised keys, insufficient entropy
  • Algorithm - SHA-1 CSRs rejected; use SHA-256 or SHA-384
  • Domain issues - Internal names (.local, .internal), IPs in SAN without validation, wildcard restrictions
  • Formatting - PEM encoding required, no corruption, proper BEGIN/END markers
  • Rate limits - Let's Encrypt: 5 duplicate certificates per exact SAN set per 7 days; 50 certificates per registered domain per 7 days (renewals with identical SANs hit duplicate limit, not the 50/domain limit)

The Rejection Email Nobody Wants

You did everything right. Generated the key, created the CSR, submitted to your CA. Then you get the email:

"Your certificate signing request could not be processed. Please correct the following issues and resubmit."

Sometimes the error message is helpful. Often it's cryptic. And occasionally you get no explanation at all.

The Good News

CSR rejections fall into predictable categories. Once you know what CAs are checking, you can fix the problem and resubmit - usually within minutes.

The Bad News

Some rejections require generating a completely new key pair. That's why understanding the requirements before you generate saves time.

Use our CSR Checker before submitting to catch issues early, or check the OpenSSL CSR Guide for generating a proper CSR from the start.

Key-Related Rejections

These are the most common rejections - and often require regenerating your key pair.

Rejection: Key Size Too Small

AlgorithmMinimum SizeRecommendedRejected
RSA2048-bit3072 or 4096-bit1024-bit, 512-bit
ECDSAP-256 (256-bit)P-384P-192, smaller curves
EdDSAEd25519Ed25519-

Note on Ed25519: While Ed25519 is widely used and secure, not all public WebPKI CAs accept it yet. Check your CA's supported algorithms before generating an Ed25519 key.

Why it happens: You're using an old key, old documentation, or legacy scripts that specify outdated key sizes. RSA-1024 was deprecated years ago but still appears in legacy configs.

The fix:

# Generate proper RSA key
openssl genrsa -out private.key 3072

# Or generate ECC key (smaller, faster)
openssl ecparam -name prime256v1 -genkey -noout -out private.key

Check your existing key:

openssl rsa -in private.key -text -noout | grep "Private-Key"
# Should show: Private-Key: (2048 bit) or higher

Rejection: Weak Key Detected

CAs maintain databases of known-weak keys and will reject CSRs using them.

Sources of weak keys:

SourceProblemHow to Check
Debian OpenSSL bug (2006-2008)Only 32,767 possible keys per key sizedebian-weak-keys lookup
Insufficient entropyGenerated on system with bad randomnessCan't detect after the fact
Known compromisedKey appeared in breach databaseCA's internal checks
Factorable keysMathematical weakness discoveredResearch databases and key-reuse datasets
The Debian Weak Key Disaster

From 2006-2008, a bug in Debian's OpenSSL package caused the random number generator to be seeded with only the process ID. This meant only ~32,767 unique keys could ever be generated for each key size. If you're using a key generated on Debian, Ubuntu, or derivatives during this period, it's in a known-weak-keys database.

The fix: Generate a new key. There's no way to "strengthen" a weak key.

# Always generate fresh keys on a properly configured system
openssl genrsa -out private.key 3072

# Verify entropy source is working (Linux)
cat /proc/sys/kernel/random/entropy_avail
# Should be > 256

For more on secure key generation, see our OpenSSL Key Generation Guide.

Rejection: Key Previously Compromised

If your private key has ever been:

  • • Posted publicly (GitHub, Pastebin, etc.)
  • • Submitted to certificate transparency logs by mistake
  • • Part of a breach disclosure
  • • Reported to the CA as compromised

...the CA will reject any CSR using that key.

How CAs detect this:

  • • Monitoring CT logs for private key submissions
  • • Databases of known-compromised keys (from breaches)
  • • Cross-referencing with previous revocation requests

The fix: Generate a completely new key pair. Never reuse a compromised key.

Rejection: Signature Algorithm Not Accepted

Your CSR is signed with an algorithm the CA won't accept.

AlgorithmStatusNotes
SHA-256 AcceptedStandard choice
SHA-384 AcceptedRequired for some ECC
SHA-512 Usually acceptedCheck CA requirements
SHA-1 RejectedDeprecated since 2017
MD5 RejectedBroken, never use

The fix:

# Generate CSR with SHA-256 (default in modern OpenSSL)
openssl req -new -key private.key -out request.csr -sha256

# Verify CSR signature algorithm
openssl req -in request.csr -text -noout | grep "Signature Algorithm"

Domain-Related Rejections

The second most common category. These don't require new keys - just a new CSR with correct domain information.

Rejection: Domain Validation Failed

The CA couldn't verify you control the domain(s) in your CSR.

Common causes:

  • • DNS not propagated yet
  • • HTTP challenge file not accessible
  • • Email going to wrong address
  • • CAA record blocking the CA

The fix: This isn't a CSR problem - it's a validation problem. See the Domain Validation Methods Guide.

Rejection: Internal/Non-Public Domain Names

CAs cannot issue publicly-trusted certificates for:

Domain TypeExampleWhy Rejected
.local TLDserver.localReserved for mDNS
.internal TLDapp.internalNot publicly resolvable
.lan TLDprinter.lanHome network convention
.corp / .home TLDmail.corpReserved
Single-label namesSERVER1Not a valid FQDN
Reserved nameslocalhost, example.comIANA reserved (example.com is reserved for documentation and cannot be used for production certificates)

The fix:

  • • Use a real domain you own and create subdomains
  • • Use a private CA for internal systems
  • • Consider split-horizon DNS

Example: Instead of app.internal, use app.internal.yourcompany.com where you own yourcompany.com.

For internal systems, see our Self-Signed Certificates Guide.

Rejection: IP Address Issues

IP addresses in certificates have specific requirements.

ScenarioStatusNotes
Public IP in SAN AllowedRequires IP validation
Private IP (10.x, 192.168.x, 172.16-31.x) RejectedCan't be validated publicly
Loopback (127.0.0.1) RejectedReserved
IPv6 link-local RejectedNot publicly routable
IP in Common Name (CN) only DeprecatedMust be in SAN

The fix: If you need certificates for private IPs, use a private CA. Public CAs can only issue for public IPs they can validate.

Rejection: Wildcard Restrictions

Wildcards have specific rules that cause rejections.

PatternStatusNotes
*.example.com ValidCovers one label only (foo.example.com, not bar.foo.example.com)
*.*.example.com RejectedMulti-level wildcards not allowed
example.* RejectedWildcard must be leftmost
sub.*.example.com RejectedWildcard must be leftmost
*.com RejectedCan't wildcard public suffix
*.co.uk RejectedCan't wildcard public suffix
Important

A wildcard certificate for *.example.com does NOT cover example.com itself. You need both in your SAN if you want both.

The fix: Restructure your SAN list to comply with wildcard rules.

For more on wildcard risks, see our Wildcard Certificate Dangers Guide.

Rejection: CAA Record Blocking

Your domain has a CAA (Certificate Authority Authorization) record that doesn't include the CA you're using.

Check your CAA records:

dig example.com CAA +short
# Output might show: 0 issue "letsencrypt.org"
# This means ONLY Let's Encrypt can issue

The fix:

  • • Add your CA to the CAA record
  • • Or remove the CAA record (allows all CAs)
  • • Or switch to a CA that's already authorized
# Example CAA record allowing multiple CAs
example.com. CAA 0 issue "digicert.com"
example.com. CAA 0 issue "letsencrypt.org"
example.com. CAA 0 issue "sectigo.com"

Learn more in our CAA Records Explained Guide.

Formatting and Encoding Rejections

These are frustrating because the CSR might be valid but the CA can't parse it.

Rejection: Invalid PEM Encoding

PEM format requires:

  • • Header: -----BEGIN CERTIFICATE REQUEST-----
  • • Base64-encoded content (64 characters per line)
  • • Footer: -----END CERTIFICATE REQUEST-----

Common corruption causes:

  • • Copying from terminal added line breaks
  • • Email client wrapped lines
  • • Windows CRLF vs Unix LF issues
  • • Editor added invisible characters (BOM)

The fix:

# Verify CSR format is valid
openssl req -in request.csr -text -noout

# If it fails, check for encoding issues
file request.csr
# Should show: "PEM certificate request"

# Convert if needed (DER to PEM)
openssl req -in request.der -inform DER -out request.pem -outform PEM

Pro tip: Always use cat to display CSR before submitting to verify no corruption: cat request.csr

Rejection: Mismatched Key and CSR

The CSR wasn't signed by the private key you're trying to use.

How this happens:

  • • Generated new key but used old CSR
  • • Copied wrong file
  • • Key file overwritten between generation and CSR creation

The fix:

# Verify CSR and key match
openssl req -in request.csr -noout -pubkey > csr_pubkey.pem
openssl rsa -in private.key -pubout > key_pubkey.pem
diff csr_pubkey.pem key_pubkey.pem
# Should show no differences

If they don't match, generate a new CSR with the correct key:

openssl req -new -key private.key -out request.csr

Rejection: Invalid Characters in Fields

CSR fields have character restrictions.

FieldRestrictions
Common NameNo wildcards except at leftmost position; valid FQDN
OrganizationPrintable ASCII; some CAs restrict special characters
CountryExactly 2 letters (ISO 3166-1 alpha-2)
EmailValid email format
All fieldsNo null bytes, no control characters

The fix: Regenerate CSR with corrected field values.

# Check current CSR contents
openssl req -in request.csr -text -noout

# Look at Subject line for issues

CA-Specific Rejections

Each CA has policies beyond the baseline requirements.

Rejection: Rate Limited

You've requested too many certificates in a time window.

Let's Encrypt Limits:

LimitValueReset
Certificates per registered domain50 per 7 daysRolling window
Duplicate certificates (exact same SAN set)5 per 7 daysRolling window
Failed validations5/hourRolling 1 hour
New orders300/3 hoursRolling 3 hours

The fix: Wait for the rate limit to reset, or use staging environment for testing.

# Use Let's Encrypt staging for testing
certbot certonly --staging -d example.com

Rejection: High-Risk Domain

Some CAs flag certain domains for additional review or outright rejection:

  • • Domains containing brand names (apple, google, microsoft)
  • • Domains similar to financial institutions (phishy-looking finance domains like "secure-banklogin.com" often trigger extra review)
  • • Previously-phished domains
  • • Domains on blocklists

The fix: Contact CA support for manual review. Be prepared to explain the legitimate purpose of your domain and provide additional verification if requested. Alternatively, choose a different CA.

Rejection: Subscriber Agreement Not Accepted

Some CAs require explicit acceptance of updated terms before processing CSRs.

The fix: Log into CA portal and accept the updated subscriber agreement.

For more on what you're agreeing to, see our Certificate Subscriber Obligations Guide.

Validation-Specific Rejections

Rejection: Organization Validation Failed (OV/EV)

For OV and EV certificates, the CA couldn't verify your organization.

Common causes:

  • • Organization name doesn't match business registry exactly
  • • Address doesn't match official records
  • • Phone number can't be verified
  • • Organization too new (some CAs require operating history)

The fix: Ensure CSR organization details match exactly what's in public business registries (state filings, Dun & Bradstreet, etc.).

Rejection: Extended Validation Requirements Not Met (EV)

EV has the strictest requirements.

Common EV rejections:

  • • Requester not listed as authorized certificate contact
  • • Organization not in good standing with state
  • • Domain not owned by the organization (registered to individual)
  • • Required documentation not submitted

The fix: Work with your CA's validation team to understand exactly what documentation they need.

Learn more about certificate types in our DV vs OV vs EV Certificates Guide.

Prevention - Get It Right the First Time

Pre-Submission Checklist

  1. 1Key size - RSA 2048+ or ECC P-256+
  2. 2Fresh key - Generated on secure system with good entropy
  3. 3Algorithm - SHA-256 or higher for CSR signature
  4. 4Domain names - All publicly resolvable FQDNs
  5. 5Wildcard format - Only at leftmost position
  6. 6CAA records - Allow your CA
  7. 7PEM format - Valid encoding, no corruption
  8. 8CSR/key match - Verify before submitting

Use the CSR Checker Before Submitting

Our CSR Checker validates:

  • • Key size and algorithm
  • • CSR signature validity
  • • Domain format issues
  • • Field encoding problems

OpenSSL One-Liner for a Good CSR

This generates a 3072-bit RSA key and CSR with proper SAN entries in one command:

openssl req -new \
  -newkey rsa:3072 \
  -nodes \
  -keyout private.key \
  -out request.csr \
  -subj "/C=US/ST=State/L=City/O=Organization/CN=www.example.com" \
  -addext "subjectAltName=DNS:www.example.com,DNS:example.com" \
  -sha256

For more details, see our OpenSSL CSR Generation Guide.

FAQ

Can I reuse my private key after a CSR rejection?

Usually yes, unless the rejection was for a weak or compromised key. If the rejection was for domain issues, formatting, or CA policy, generate a new CSR with the same key.

How quickly can I resubmit after fixing the issue?

Immediately, unless you hit rate limits. Most CAs have no waiting period between submissions.

My CSR worked at one CA but was rejected at another. Why?

CAs can have different policies beyond the baseline requirements. Key size minimums, domain restrictions, and validation requirements can vary. Check the specific CA's documentation.

How do I know if my key is in a weak-keys database?

Use tools like openssl-vulnkey (Debian) or online weak key checkers to verify your keys before submitting a CSR.

Can I see exactly why my CSR was rejected?

Contact your CA's support. The rejection email often has minimal detail, but support can explain the specific validation failure.

Does generating a new CSR invalidate my old private key?

No. You can generate unlimited CSRs from the same private key. The key is only "used up" once a certificate is issued - and even then, you can renew with the same key (though rotation is better practice).

Quick Reference - Error Messages

Common error messages and what they mean:

Error MessageLikely CauseFix
"Key size does not meet minimum requirements"RSA < 2048 or ECC < P-256Generate larger key
"CSR signature verification failed"Corrupted CSR or wrong keyRegenerate CSR
"Invalid domain name"Internal TLD or invalid formatUse public FQDN
"CAA record forbids issuance"CAA doesn't list CAUpdate CAA records
"Rate limit exceeded"Too many requestsWait and retry
"Weak key detected"Debian bug or low entropyGenerate new key
"Unable to validate domain"DNS/HTTP challenge failedCheck validation setup
"Organization validation failed"Name/address mismatchMatch official records
"High-risk domain"Domain flagged for reviewContact CA support
"Public key already in use"Key used for existing certGenerate new key

Key Takeaways

  1. 1Check key size first - RSA 2048+ or ECC P-256+ is mandatory everywhere
  2. 2Weak keys can't be fixed - You must generate a new key pair
  3. 3Internal domains are dead - .local, .internal won't work with public CAs
  4. 4Wildcards have rules - Leftmost label only, can't span public suffixes
  5. 5CAA can block you - Check DNS before submitting
  6. 6Use the CSR Checker - Validate before you submit to catch obvious issues

Related Content