## TL;DR
The server answers every Host header with the same certificate, so connection success means nothing. Baseline the wildcard response with a nonsense Host header, filter it by length and status, and confirm remaining candidates by distinct content, cross-checked against DNS and certificate transparency data.

```text
wildcard certificate false positives
```

## Use this when
- Gobuster vhost mode reports hits for obviously fake hostnames.
- The target serves a default certificate for any SNI/Host value.
- The engagement covers virtual host discovery on the domain.

## Not for this skill when
- The server presents distinct certificates per vhost. Then connection success is meaningful.
- You are doing DNS enumeration instead. Use DNS tooling for that.
- The domain is out of scope. Do not enumerate its vhosts.

## Steps
1. Baseline the wildcard: `curl -s -o /dev/null -w "%{http_code} %{size_download}" -H "Host: definitely-not-real-12345.target.com" YOUR_TARGET_HOST`. Verify: you have the wildcard signature.
2. Filter it: add `--exclude-length` matching the wildcard size (and `-b` for its status if constant). Verify: the fake hostname no longer reports as a hit.
3. Rerun the vhost scan with the filter in place. Verify: remaining candidates are far fewer.
4. Confirm each candidate by content: fetch it and diff against the wildcard baseline. Verify: the body differs, not just timing.
5. Cross-check survivors against DNS records and certificate transparency logs. Verify: candidates resolve or appear in CT independently.

## Variant phrasings
### gobuster vhost wildcard false positive
Compact phrasing.
### gobuster vhost scan all hosts succeed
Symptom-level search.
### vhost enumeration wildcard certificate
The technique-level search.

Compatibility: gobuster v3.x vhost mode. `--exclude-length` filtering applies to vhost mode as well as dir mode.

## Why it happens
Many servers present a default certificate when SNI does not match a configured vhost, and the TLS handshake succeeding says nothing about whether the vhost exists. Gobuster's default vhost logic counts distinctive responses as hits, but a wildcard-everything server makes every guess look distinctive-free yet "successful".

## Edge cases / pitfalls
- Some apps vary the wildcard page per request (timestamps, nonces). Size filtering gets brittle; add content matching.
- A real vhost can share the wildcard's size by coincidence. Content diffing, not size alone, is the confirmation.
- Do not report unconfirmed vhost candidates as findings. An unconfirmed vhost is a lead, not a vulnerability.
- CT logs only show publicly trusted certs; internal vhosts will not appear there. Note the limitation.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_H9XQXJpzsG2R7Iz9Fn3sxg