MITM certificates carry no SAN for ordinary hostnames #4

New issue

Closed

opened 2026-10-26 20:23:15 +00:00 by mikluko · 0 comments

mikluko commented

2026-10-26 20:23:15 +00:00

Owner

certForRequest in pkg/handlers/handler_mitm.go inverts the error check on publicsuffix.EffectiveTLDPlusOne:

tldplus, err := publicsuffix.EffectiveTLDPlusOne(hostname)
if err != nil {
    cn = tldplus
    dnsnames = append(dnsnames, tldplus, "."+tldplus)
} else {
    cn = hostname
}

For any ordinary hostname the lookup succeeds, so the issued certificate has a CN and no DNSNames. Go clients refuse it:

x509: certificate relies on legacy Common Name field, use SANs instead

curl accepts it, which is why it goes unnoticed. The requested hostname should always be in DNSNames (an IP in IPAddresses); a wildcard for the eTLD+1 can be added on top.

`certForRequest` in `pkg/handlers/handler_mitm.go` inverts the error check on `publicsuffix.EffectiveTLDPlusOne`: ```go tldplus, err := publicsuffix.EffectiveTLDPlusOne(hostname) if err != nil { cn = tldplus dnsnames = append(dnsnames, tldplus, "."+tldplus) } else { cn = hostname } ``` For any ordinary hostname the lookup succeeds, so the issued certificate has a CN and no `DNSNames`. Go clients refuse it: ``` x509: certificate relies on legacy Common Name field, use SANs instead ``` curl accepts it, which is why it goes unnoticed. The requested hostname should always be in `DNSNames` (an IP in `IPAddresses`); a wildcard for the eTLD+1 can be added on top.

mikluko added the

bug

label

2026-10-26 20:23:15 +00:00

mikluko referenced this issue from a pull request that will close it,

2026-10-26 20:50:27 +00:00

MITM certificates name the requested host as a SAN #28

mikluko closed this issue

2026-10-26 20:51:47 +00:00