OpenSSL req is commonly used to create and inspect certificate signing requests and self-signed certificates. In practice, a team uses it to generate a key pair and CSR for a new service, then verifies the requested subject details before issuance. Check the request carefully to avoid approving the wrong identity or naming scope.
What openssl req is doing in a real workflow
In practice, openssl req is the step where a team turns an intended service identity into a request that a certificate authority can issue. You use it to create a private key and certificate signing request, or to inspect an existing CSR before it is approved. That makes it part of the trust and naming workflow, not just a syntax exercise.
A typical use case is onboarding a new internal service that needs TLS. The operator generates a key pair, builds a CSR with the required subject fields, then checks that the common name and subject alternative names match the actual service scope before submission. The same command is also used with self-signed certificates in test environments, where the goal is local trust rather than external issuance.
The practical value is that the request captures what the certificate will represent. If the subject details are wrong, the wrong hostname, team, or environment can be approved into the certificate chain. That is why operators often treat CSR review as a control point, not a clerical step. The command is useful precisely because it lets you see and shape the identity data before a certificate is issued.
What to check before you approve the CSR
openssl req is most useful when the operator validates the request, not just creates it. The subject fields should reflect the real service name, environment, and any DNS names that will be used by clients. If the CSR is for an API, load balancer, or internal service mesh workload, the SAN list matters more than a single human-readable subject line.
It is also worth checking whether the request is being used for production issuance or for a development certificate. Test certificates often tolerate looser naming, but that habit should not bleed into production. A CSR that is accurate for one environment can still be wrong for another if the naming scope, trust domain, or issuing policy differs.
For teams that manage many service certificates, the command is usually embedded in a larger issuance process. The operator prepares the CSR, the approver confirms the subject details, and the issuer signs only after the request matches policy. NIST SP 800-53 Rev 5 Security and Privacy Controls is a useful reference when you want to map that approval step to broader access and credential governance.
For certificate material that will be used by services and other non-human workloads, the lifecycle matters as much as the initial request. OWASP Non-Human Identity Top 10 is relevant because the CSR is often the first point where a workload identity becomes formalised and later governed.
Example commands and the operational follow-through
A basic example is generating a new private key and CSR in one step, then reviewing the resulting request before it is sent onward. Another common pattern is opening an existing CSR to confirm its contents, especially when a colleague or automation pipeline produced it. The command itself is simple, but the operational follow-through is what makes it safe: review, compare against the intended service, then submit only if the naming is correct.
In self-signed scenarios, the same workflow is used to create a certificate directly for a lab or prototype system. That can be useful for early testing, but it should not hide the fact that the certificate is still asserting an identity. If the wrong subject is copied forward from a lab to production, clients may trust a certificate that names the wrong thing.
When teams automate certificate creation, they should still preserve a manual approval checkpoint for any request that will affect production trust boundaries. The command can be automated; the naming decision should still be reviewed. For broader controls around authentication and certificate handling, NIST SP 800-63 Digital Identity Guidelines is helpful when the certificate is part of a larger identity and assurance model.
For key lifecycle considerations, especially when the CSR workflow is paired with key generation and rotation, NIST SP 800-57 Key Management is the right companion reference because the private key and the certificate request must be governed together.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST SP 800-57 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | CSR and certificate workflow depends on controlled issuance and lifecycle of key material. |
| IA-9 — Service Authentication | Service CSRs create credentials used by non-human systems to authenticate. | |
| AC-2 — Account Management | CSR approval often reflects governance over service ownership and identity scope. | |
| Recommendation — Manage certificate and key lifecycle so issued credentials match the approved service identity. Use service authentication controls to bind certificates to the correct workload or API. Keep certificate issuance tied to an owned, reviewed identity record. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Certificate requests and issued certs must be removed when a service is retired. |
| NHI-07 — Long-Lived Secrets | CSRs often lead to certificates and keys that can become long-lived if unmanaged. | |
| Recommendation — Revoke and retire certificates when the non-human identity is decommissioned. Set rotation and expiry rules so certificate material does not linger indefinitely. | ||
| NIST SP 800-57 | Key Management | The question concerns generating and governing a certificate key pair and CSR. |
| Recommendation — Define key generation, storage, rotation, and destruction rules alongside CSR issuance. | ||
Practitioner Guidance
What to verify: Treat the CSR as a trust boundary artifact. Verify the subject, SANs, environment name, and intended service owner before approval, because those fields determine what the issued certificate will actually represent.
Common mistake: Teams often focus on command syntax and ignore naming scope. The usual failure is not generating a CSR, it is approving a technically valid CSR for the wrong service or environment.
Decision rule: If the request will be used in production or for an externally trusted service, require explicit review of the subject details and key ownership before issuance. If it is only for a lab, keep the process lighter, but do not let lab naming patterns become your production default.
Practitioner takeaway: The command is only the mechanism, the security decision is whether the CSR accurately describes the identity that will be trusted.