openssl ca与openssl x509命令差异及证书字段写入问题咨询

Great question! I’ve run into this exact quirk with OpenSSL’s CA tools before, so let me break down the core differences between these two commands—and why your cellphone and emailAddress fields aren’t making it into certificates when using openssl ca.

1. Core Purpose & Workflow Context #

• openssl ca: This is a specialized CA management tool built for running a formal Certificate Authority (like your root and intermediate CA setup). It enforces strict CA workflows, relying entirely on your ca.cnf configuration to govern every aspect of certificate issuance: from subject field validation to maintaining certificate databases, CRLs, and serial number sequences. It’s designed to keep your CA infrastructure compliant and consistent.
• openssl x509: This is a generic, flexible X.509 certificate manipulation tool. It doesn’t care about CA workflows or configuration rules—it simply processes certificate signing requests (CSRs) or existing certificates directly. You can use it to generate, modify, or inspect certificates without adhering to formal CA procedures.

2. Why cellphone and emailAddress Are Missing in openssl ca Output #

The root issue here is field inclusion rules enforced by your ca.cnf:

• openssl ca checks the policy section of your configuration to determine which subject fields are allowed to be included in issued certificates. By default, most CA configs use a restrictive policy that only permits common fields like countryName, stateOrProvinceName, organizationName, and commonName. If cellphone and emailAddress aren’t explicitly marked as allowed in the policy, openssl ca will silently exclude them from the final certificate—even if they’re present in the CSR.
• In contrast, openssl x509 doesn’t enforce any policy rules. It copies all subject fields directly from the CSR to the certificate, no questions asked. That’s why your fields show up when using this command.

3. Flexibility vs. Compliance Tradeoff #

• openssl ca: Best suited for production-grade CA setups. It ensures you follow industry standards, maintains audit trails (via the certificate database), and prevents misissuance. But this strictness comes at the cost of flexibility—you can’t just add arbitrary fields without updating your config.
• openssl x509: Ideal for testing, quick certificate generation, or custom use cases where you don’t need formal CA governance. It’s fast and flexible, but it doesn’t track issued certificates or maintain CA state, making it unsuitable for managing a trusted CA hierarchy.

4. Fixing the openssl ca Field Issue #

To get cellphone and emailAddress into certificates issued by openssl ca, update your ca.cnf:

1. Locate the policy section (likely named policy_match or policy_anything).
2. Add explicit rules to allow your fields. For example:

   [policy_anything]
   countryName             = optional
   stateOrProvinceName     = optional
   localityName            = optional
   organizationName        = optional
   organizationalUnitName  = optional
   commonName              = supplied
   emailAddress            = optional
   cellphone               = optional
   

   Note: Ensure the field name (cellphone) matches exactly what’s in your CSR. If you’re using a custom OID for cellphone, you may need to map it in the [names] section of your config.
3. Re-run your openssl ca command with the updated config—your fields should now appear in the issued certificate.

内容的提问来源于stack exchange，提问作者Jeff Pal