Directory meta caaIdentities should accept null

[mdegel]

Bug Overview

When an ACME directory's meta.caaIdentities field is null (or omitted), deserialization fails because the client expects an array. The code currently defines the field as Vec<String>, which rejects null values and produces an error such as:

directory update failed (cannot deserialize response (invalid type: null, expected a sequence at line 1 column 680)) while creating account for acme issuer "acme_config"

RFC8555 specifies caaIdentities as an optional array of strings; servers may omit it or set it to null.

The client defines this field as a non-optional vector:

• File: src/acme/types.rs
• Struct: DirectoryMetadata
• Current field: pub caa_identities: Vec<String>,

serde attempts to deserialize null into Vec<String> and fails with an "invalid type: null, expected a sequence" error.

Expected Behavior

null values should be acceptable

Steps to Reproduce the Bug

• Use an ACME directory whose meta contains "caaIdentities": null (or omit the field entirely).
• Trigger directory fetch/account creation (e.g., start or reload NGINX).
• Observe the error in the error log and failure to proceed past directory fetch.

Environment Details

• Target deployment platform: Docker Image
• Target OS: Debian Trixie
• Version of this project or specific commit: v0.2.0
• Version of any relevant project languages: rustc 1.90.0

Additional Context

Proposed Fix

• Change the field type to accept null values while preserving existing behavior for arrays:

  • Update DirectoryMetadata:
    • pub caa_identities: Option<Vec<String>>,

• Rationale:

  • Matches RFC8555 semantics (optional field).
  • Option<Vec<_>> deserializes both null and omitted values; arrays continue to work unchanged.
  • Minimal, backward-compatible change for callers that already handle absence of the field.

References

• RFC8555: https://www.rfc-editor.org/rfc/rfc8555