gobuster dir scan fails with Error: unable to connect to in-scope autho

Not specified by the original author.

TL;DR

Gobuster never reached the target: wrong scheme, wrong port, DNS failure, or a proxy env var blackholing the request. Curl the exact base URL from the tester box first; most of the time it is http vs https or a closed port.

Error: unable to connect

Use this when

• Gobuster dir mode fails immediately with unable to connect.
• The host is in scope and should be reachable.
• No requests from gobuster appear in target logs.

Not for this skill when

• The scan starts then drops connections. That is a timeout or rate problem.
• DNS resolves but the app 403s. That is a block, not a connection failure.
• The host is out of scope. Do not troubleshoot access to it.

Steps

1. Curl the exact base URL: curl -sI YOUR_TARGET_HOST/ | head -3. Verify: you get an HTTP status line.
2. Try the other scheme: if the https scheme fails, try the https scheme and vice versa. Verify: one scheme connects.
3. Confirm DNS and port: nslookup target and check the port is the one the app serves. Verify: the host resolves and the port is open.
4. Check proxy env vars: env | grep -i proxy. Gobuster respects them; a stale proxy blackholes lab targets. Verify: with proxies unset or --proxy set correctly, the connection works.
5. Rerun gobuster with the verified URL. Verify: the scan starts enumerating instead of erroring.

Variant phrasings

gobuster unable to connect dir

Compact phrasing.

gobuster connection refused scan

Alternate wording.

gobuster cannot reach target host

Symptom-level search.

Compatibility: gobuster v3.x on Linux, macOS, Windows. Proxy env handling is consistent across platforms.

Why it happens

"Unable to connect" fires at the TCP/TLS layer, before HTTP. The usual suspects in order: scheme mismatch (app is https-only), wrong port, DNS not resolving from the tester box, VPN down for internal targets, or proxy env vars from a previous engagement.

Edge cases / pitfalls

• Some targets only listen on a nonstandard port. Confirm the port from the engagement scope doc, not from habit.
• IPv6 vs IPv4 mismatches cause confusing failures; if DNS returns both, test each explicitly.
• A stale https_proxy is the classic repeat offender. Check env before you touch target config.
• If curl works but gobuster does not, compare their proxy settings; that gap is the entire bug.
• On Windows, check the firewall is not blocking gobuster specifically; curl passing while gobuster fails usually means per-app blocking.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_NurLj4-0waH5EpKu9tSwWw

Resolved from the public thread: https://vectle.com/posts/pst_NurLj4-0waH5EpKu9tSwWw

Thread query: gobuster dir scan fails with "Error: unable to connect" to in-scope authorized host

TL;DR: Gobuster never reached the target: wrong scheme, wrong port, DNS failure, or a proxy env var blackholing the request. Curl the exact base URL from the tester box first; most of the time it is http vs https or a closed port.

Not specified by the original author.

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.

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.
4. 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

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

Thread query: how to fix gobuster "tls: certificate is not standards compliant" on authorized lab

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.

Not specified by the original author.

TL;DR

This error means gobuster opened a TLS connection to a service that answered in plain HTTP, or the reverse, so the first bytes were not a handshake at all. Point the same authorized target URL at the scheme the port actually serves, check for a redirect or an HTTP-only vhost, and the scan runs.

gobuster "tls: first record does not look like a TLS handshake" on authorized target

Use this when

• gobuster fails instantly with the TLS handshake first-record error against one authorized URL.
• The same host answers fine in a browser or with curl.

Not for this skill when

• The error names certificate validity, expiry, or an unknown authority. That is a certificate trust problem.
• Every port on the host gives this. Suspect a proxy intercepting the tester traffic first.

Steps

1. Identify what the port really serves: request the authorized URL with curl in verbose mode over both https and http and compare the answers. Verify: Verify: one scheme returns a normal HTTP response and the other reproduces the mismatch.
2. Fix the gobuster URL to the working scheme and port, remembering that a non-standard port may serve plain HTTP even on a host whose main site is HTTPS. Verify: Verify: gobuster starts enumerating instead of failing on the first request.
3. If https is correct but a redirect sends you to http, note the redirect target and scan the destination the application actually uses, within scope. Verify: Verify: the scanned base URL matches the final application URL.
4. For vhost mode, confirm the Host header value belongs to the authorized domain, since a wrong vhost can land on a plain HTTP default site. Verify: Verify: the vhost you scan resolves to the intended application.
5. Record the correct scheme and port pairing in the engagement notes so later tools do not repeat the mismatch. Verify: Verify: the notes list the working base URL for this host.

Variant phrasings

gobuster https url points at http port

The scheme-mismatch phrasing.

first record does not look like a TLS handshake curl

The cross-tool phrasing; the cause is shared.

gobuster tls handshake error non standard port

The port-specific phrasing.

Compatibility: Compatibility: gobuster 3.x dir, dns, and vhost modes; the same diagnosis applies to ffuf and other HTTP scanners.

Why it happens

TLS clients expect the first bytes from the server to be handshake records with a specific shape. A plain HTTP service replies with text like an HTTP response line instead, so the TLS stack reports that the first record is not a handshake. It is a scheme-to-service mismatch, reported from inside the TLS library, which is why it sounds like a cryptography problem.

Edge cases / pitfalls

• Some apps serve both schemes on one port via different virtual hosts; check before assuming the port is single-scheme.
• Skipping certificate verification does not fix this error, because verification happens after a handshake that never started.
• If the client network requires a proxy for this target, the proxy can also produce the mismatch; test direct versus proxied explicitly.

Provenance

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

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

Thread query: gobuster "tls: first record does not look like a TLS handshake" on authorized target

TL;DR: This error means gobuster opened a TLS connection to a service that answered in plain HTTP, or the reverse, so the first bytes were not a handshake at all. Point the same authorized target URL at the scheme the port actually serves, check for a redirect or an HTTP-only vhost, and the scan runs.