Skip to content

docs(ssl): let the product decide whether a multi-domain certificate takes a wildcard - #642

Open
phlima95 wants to merge 1 commit into
mainfrom
docs/ssl-multidomain-wildcard-product
Open

docs(ssl): let the product decide whether a multi-domain certificate takes a wildcard#642
phlima95 wants to merge 1 commit into
mainfrom
docs/ssl-multidomain-wildcard-product

Conversation

@phlima95

Copy link
Copy Markdown
Contributor

Description

The SSL documentation stated, as an absolute rule, that a multi-domain certificate cannot contain a wildcard. That stops being true: two new products, SSL MDC Wildcard DV and SSL SAN Wildcard DV, are sold with wildcard coverage, while SSL MDC DV and SSL SAN DV go on refusing one. Whether a wildcard is accepted is now a property of the product, not of the coverage.

Changes Made

  • ssl-certificates.md — the coverage table gained a Multi-domain with wildcard row naming the two new products.
  • ssl-certificates.md — the "Which combinations are allowed" rule was rewritten: it names which multi-domain products accept a wildcard and which refuse one, notes that a wildcard takes one of the certificate's domain slots like any other domain, and keeps the EV refusal explicit.
  • ssl-certificates.md — the "Choosing" tip covers the case of needing a fixed set of domains where one has to be a wildcard.
  • issuing-a-certificate.md — the Common Name field no longer reads as though every product with "Wildcard" in its name requires a *. common name. A single-domain wildcard product requires it; a multi-domain wildcard product accepts it without requiring it.
  • issuing-a-certificate.md — the troubleshooting table quoted Multi-domain certificates do not accept wildcards in the Common Name or SANs, a message the wizard no longer emits and has not emitted since wildcards were first allowed on multi-domain products. It now carries the message the wizard actually shows, and names the products that resolve it.

Related Issues

Documents the behaviour shipped by the platform PRs of the same change: convisoappsec/platform-backend#14466, convisoappsec/platform-frontend#3124 and convisoappsec/conviso-backoffice#130.

Testing

yarn build succeeds. The nine broken-anchor warnings it reports are pre-existing and all live in other pages (conviso-mcp-server, github-actions, gitlab, powerbi); the SSL pages report none.

Checklist

  • Code review
  • Tests pass
  • Documentation updated (if applicable)

Additional Comments

Should merge once the platform PRs are deployed, not before: until then the documented behaviour is ahead of what the platform does.

The 4.26 release note was left untouched — it describes the SSL module in general terms and does not mention wildcards on multi-domain products.

…takes a wildcard

Whether a multi-domain certificate can carry a wildcard is no longer a
property of the coverage: SSL MDC DV and SSL SAN DV refuse one, and the
new SSL MDC Wildcard DV and SSL SAN Wildcard DV accept it in the Common
Name and among the additional domains alike.

The troubleshooting table quoted a message the wizard stopped emitting
before this change. It now carries the message the wizard actually
shows, and says which products resolve it.
@conviso-platform-appsec

Copy link
Copy Markdown

Conviso Security Gate — No Security Gate rule configured

No conviso_ast rule and no default rule are configured for this asset or company, so there is no policy to evaluate. Nothing was passed or failed.

No new findings were introduced by this pull request.

View the full run in Conviso

@phlima95 phlima95 self-assigned this Aug 31, 2026
@phlima95
phlima95 marked this pull request as ready for review August 31, 2026 19:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants