Is Your Origin Ready for Cloudflare Full (Strict)?
How can a small business check whether its origin is ready for Cloudflare Full (strict)?
Your origin is a candidate for Full (strict) when it presents a certificate issued by a publicly trusted certificate authority or Cloudflare Origin CA. Record the certificate source, decision owner and person responsible for resolving any issue before changing the setting. If certificate suitability is uncertain, pause and verify it rather than guessing or treating Full as an equivalent long-term configuration.
Confirm the intended encrypted path
Cloudflare documents that Full (strict) encrypts traffic going to and coming from Cloudflare. Use that documented path as the intended outcome in a readiness record, then identify the origin or hostname and the person accountable for the decision. A worksheet records what the team has confirmed; it does not independently prove that the server is correctly configured.
Sources: Full (strict) - SSL/TLS encryption modes · Cloudflare SSL/TLS docs.
- Set Full (strict) as the intended target only after readiness is established.
- State the intended encrypted connection outcome in the record.
- Keep the worksheet as a planning record, not a technical test.
Identify the origin certificate source
Cloudflare lists certificates issued by a publicly trusted certificate authority or Cloudflare Origin CA for Full (strict). For each worksheet row, record one of those certificate-source options or choose needs verification when the source is not established. Pause before a service-affecting setting change if certificate suitability remains uncertain, and confirm Cloudflare’s current prerequisites in its documentation.
Sources: Full (strict) - SSL/TLS encryption modes · Cloudflare SSL/TLS docs.
- Record one documented certificate source for each origin or hostname.
- Use needs verification when the source cannot be confirmed.
- Do not infer certificate suitability from an assumption or dashboard label.
Record ownership and a stop condition
The readiness record should name a decision owner, a person who can resolve the certificate issue and a clear stop condition for unresolved uncertainty. Use an unconfirmed certificate source as the stop condition and do not proceed until it is verified against Cloudflare’s current documentation. These ownership fields are recommended operational controls, not statements that Cloudflare requires a particular approval process.
- Name the decision owner and the person able to resolve a certificate issue.
- Use uncertainty about the certificate source as a stop condition.
- Treat these fields as operating guidance rather than vendor requirements.
Complete the readiness record
Complete one record per origin or hostname with its target mode, certificate source, decision owner, issue resolver, stop condition, decision state and next action. Mark the record ready only when the relevant details have been confirmed; otherwise mark it not ready or needs verification. Before changing a live setting, check Cloudflare’s current documentation because this record is not a complete configuration procedure or a guarantee against disruption.
- Use one row per origin or hostname.
- Choose ready, not ready or needs verification.
- Record the next action and responsible person in the same row.
Full (strict) origin readiness worksheet
Use one row for each origin or hostname. The worksheet captures the target, certificate source, decision owner, issue resolver, stop condition, decision state and next action.
| Origin or hostname | Target mode | Certificate source | Decision owner | Issue resolver, stop condition, state and next action |
|---|---|---|---|---|
| ________________ | Full (strict) | Publicly trusted certificate authority / Cloudflare Origin CA / needs verification | ________________ | Resolver: ________________; stop condition: certificate source uncertain; state: ready / not ready / needs verification; next action: ________________ |
| ________________ | Full (strict) | Publicly trusted certificate authority / Cloudflare Origin CA / needs verification | ________________ | Resolver: ________________; stop condition: certificate source uncertain; state: ready / not ready / needs verification; next action: ________________ |
Choose ready only after the listed details are confirmed. This worksheet does not test the server, provide dashboard instructions or guarantee a disruption-free change.
Related guidance
What follow-up questions matter most?
- What does this checklist confirm?
- The target is an encrypted path going to and coming from Cloudflare, together with a certificate source Cloudflare lists for Full (strict). The worksheet records readiness; it does not test the server.
- Which certificate source should I record?
- Record either a publicly trusted certificate authority or Cloudflare Origin CA as the certificate source. If neither can be confirmed, mark the record as needing verification and pause the change.
- Who should own an unresolved readiness issue?
- Record the decision owner, the person who can resolve the certificate issue and the stop condition. These are practical governance fields, not claimed Cloudflare requirements.
What steps does this workflow follow?
Create a Full (strict) origin readiness record
- Name the origin and target: Create one worksheet row for each origin or hostname being considered. Record Full (strict) as the intended target and identify the person accountable for the decision.
- Record the certificate source: Record whether the origin certificate comes from a publicly trusted certificate authority or Cloudflare Origin CA. If the source cannot be confirmed, set the decision state to needs verification.
- Apply the stop condition: Pause the change when the certificate source is uncertain. Before a service-affecting change, confirm Cloudflare's current prerequisites in its own documentation.
- Set the decision state: Choose ready only when the certificate source and ownership fields are confirmed. Otherwise record not ready or needs verification, together with the next action and responsible person.