## TL;DR
The target's certificate violates X.509 rules that Go enforces strictly, so gobuster's TLS client refuses the handshake before requesting any path. Add `-k` (`--no-tls-validation`) to the gobuster command and the scan proceeds. This is a scanner-side validation quirk, not proof the certificate is broken for browsers.

```text
tls: certificate is not standards compliant
```

## Use this when
- `gobuster dir` or `gobuster vhost` against an HTTPS target in your authorized scope fails with this exact error.
- The same URL loads fine in a browser, which tolerates more certificate quirks than Go does.
- You are on gobuster 3.x, which inherits Go's strict certificate parsing.

## Not for this skill when
- The error is `x509: certificate signed by unknown authority`. That is a trust problem with a different fix path.
- The failure is a timeout or connection refused. This skill covers only the standards-compliance parse error.
- The target sits outside your authorized scope. A certificate error never expands scope.

## Steps
1. Confirm the failing command and the exact error: run `gobuster dir -u YOUR_TARGET_HOST/ -w WORDLIST` once. Verify: the output line reads `tls: certificate is not standards compliant`.
2. Re-run with TLS validation disabled: `gobuster dir -u YOUR_TARGET_HOST/ -w WORDLIST -k`. Verify: the scan starts requesting paths instead of dying on the handshake.
3. Sanity-check the certificate independently: `openssl s_client -connect target:443 -showcerts`. Verify: you can see which field trips Go, often a negative serial number or a malformed SAN entry.
5. Record the `-k` usage in your engagement notes next to the target. Verify: whoever reviews the report can see the scan skipped certificate validation deliberately.

## Variant phrasings
### gobuster x509 standards compliant error
Same error, alternate phrasing searchers use.
### gobuster dir fails on https with tls error
Symptom-level query from the directory-scan view.

Compatibility: gobuster 3.x (Go TLS stack). The `-k` / `--no-tls-validation` flag exists in all recent 3.x builds.

## Why it happens
Go's `crypto/x509` rejects certificates that violate parts of the spec most browsers forgive: negative serial numbers, broken subject alternative name encodings, unusual signature algorithms. Gobuster inherits that strictness, so lab targets with hand-rolled or legacy certificates fail at the handshake before a single path is requested.

## Edge cases / pitfalls
- Using `-k` on a vhost scan means the TLS handshake tells you nothing about the real certificate. If certificate findings matter to the engagement, test the certificate separately with openssl.
- This error can mask a real person-in-the-middle on hostile networks. On an authorized lab it is almost always a janky lab certificate, but confirm you are on the expected network segment first.
- `-k` does not fix proxy setups or mutual TLS. If the target needs a client certificate, that configuration is still required.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_27-RwP8ajPDFZOEDztp0ew