arduino/Arduino · error · CertificateError

no appropriate commonName or subjectAltName fields were foun

Error message

no appropriate commonName or subjectAltName fields were found

What it means

This CertificateError is raised by match_hostname when the presented certificate contains NO usable CommonName or subjectAltName DNS entries at all, so there is nothing to compare the requested hostname against. It means the certificate is fundamentally unusable for hostname verification, not merely mismatched.

Source

Thrown at arduino-core/src/processing/app/i18n/python/requests/packages/urllib3/packages/ssl_match_hostname/__init__.py:60

        # in subjectAltName
        for sub in cert.get('subject', ()):
            for key, value in sub:
                # XXX according to RFC 2818, the most specific Common Name
                # must be used.
                if key == 'commonName':
                    if _dnsname_to_pat(value).match(hostname):
                        return
                    dnsnames.append(value)
    if len(dnsnames) > 1:
        raise CertificateError("hostname %r "
            "doesn't match either of %s"
            % (hostname, ', '.join(map(repr, dnsnames))))
    elif len(dnsnames) == 1:
        raise CertificateError("hostname %r "
            "doesn't match %r"
            % (hostname, dnsnames[0]))
    else:
        raise CertificateError("no appropriate commonName or "
            "subjectAltName fields were found")

View on GitHub (pinned to a0df6e0e83)

Solutions

Reissue the server certificate including proper subjectAltName dNSName entries (modern TLS ignores CN; SAN is required).
Generate the cert with SANs, e.g. `openssl req -x509 -addext 'subjectAltName=DNS:myhost.local' ...`.
If a proxy is intercepting TLS, exclude it or install its root CA and ensure it presents well-formed certificates.
Temporarily verify with cert_reqs='CERT_NONE' in a custom connection pool to confirm the diagnosis, then fix the cert.

Example fix

// before
openssl req -x509 -newkey rsa:2048 -nodes -keyout k.pem -out c.pem -subj '/CN=myhost.local'
// after
openssl req -x509 -newkey rsa:2048 -nodes -keyout k.pem -out c.pem -subj '/CN=myhost.local' -addext 'subjectAltName=DNS:myhost.local'

Defensive patterns

Strategy: try-catch

Validate before calling

import ssl, socket
ctx = ssl.create_default_context()
try:
    with ctx.wrap_socket(socket.create_connection((host, 443)), server_hostname=host) as s:
        der = s.getpeercert(True)
except ssl.SSLError as e:
    raise RuntimeError('Certificate unusable for %s: %s' % (host, e))

Try / catch

from requests.exceptions import SSLError
try:
    resp = requests.get(url, timeout=10)
except SSLError as e:
    if 'no appropriate commonName' in str(e):
        log.error('Peer certificate at %s has no SAN/CN entries; reissue it', url)
    raise

Prevention

Always generate certificates with subjectAltName entries; SAN is mandatory for modern clients.
Lint server certs in monitoring (check SAN presence with openssl x509).
Verify certs after any CA/proxy change in the environment.
Beware TLS-intercepting middleboxes; pin their root CA and ensure they re-sign properly.

When it happens

Trigger: During TLS connect(), the peer's certificate has an empty subjectAltName extension and no valid dNSName/CN fields (e.g. a cert with only an IP SAN, email SAN, or a CN of unusual type), so match_hostname builds an empty dnsnames list and falls into the else branch.

Common situations: Server using a certificate generated without -addext/-subj SANs; IP-address-only certificates on old Python (<2.7.9-style CN matching not applicable to the vendored code); enterprise MITM proxies presenting malformed certs; misconfigured CA issuing certs with only non-DNS identities.

Related errors

AI-assisted analysis of arduino/Arduino@a0df6e0e83 (2026-09-06). Data as JSON: /api/errors/e1da2dac8a47e8d5. Report an issue: GitHub.