Internet Identity id.ai outage / SSL certificate

[bitel911]

Many people from EU as well as others are getting “your connection is not private”

Did someone forget to update the SSL?

@rem.codes @dfiniitybot @kristofer

[lmuntaner]

Hi!

Thanks for reporting it.

We also noticed it and we’re working on finding the cause and fixing it.

Thanks!

[bitel911]

All caffeine apps depend on this, but I think you all understand the weight of it

Good luck, will see when its fixed

[bitel911]

Im sure you are already awate but ic0.app is not ORG, this is the core issue

[bitel911]

Grok 4 Heavy:

Hey, thanks for the additional certificate details—this helps clarify the SSL issue on id.ai. The certificate you’re viewing is issued for ic0.app (CN: ic0.app), but it includes a list of alternative DNS names (SANs) under “Niet kritiek” (non-critical extensions). Here’s the quick breakdown and why it’s causing problems:

Key Details from the Certificate

• Common Name (CN): ic0.app (primary domain).
• Alternative Names (DNS-naam/SANs): This is a multi-domain (wildcard) cert covering:
  • *.caffeine.site
  • *.caffeine.website
  • *.caffeine.xyz
  • *.dev.caffeine.xyz
  • *.ic0.app
  • *.icp0.io
  • *.icp1.io
  • *.raw.caffeine.website
  • *.raw.ic0.app
  • *.raw.icp0.io
  • *.raw.icp1.io
  • caffeine.site
  • caffeine.website
  • caffeine.xyz
  • ic0.app
  • icp-api.io
  • icp0.io
  • icp1.io
• Other Fields (from previous screenshot): Issued by Let’s Encrypt (E5), valid July 3–Oct 1, 2025, RSA keys, SHA-256 signature—all standard.
• Extensions: Non-critical (Niet kritiek), includes basic key usage for server auth. No issues there.

What’s Going Wrong?

1. Domain Mismatch: id.ai isn’t in the CN or any SAN. The cert only protects caffeine-related and IC (Internet Computer) domains like ic0.app or icp0.io. Browsers require an exact match (or wildcard like *.ai, which isn’t here), so accessing id.ai triggers ERR_CERT_COMMON_NAME_INVALID—it’s like using a lock for the wrong door.
2. Server Serving Wrong Cert: The server for id.ai is presenting this ic0.app cert instead of one for id.ai. Possible causes:
   • Misconfig in Hosting: If id.ai and ic0.app share a server (e.g., same IP via SNI), the vhost setup might default to ic0.app’s cert. Check Apache/Nginx/DFINITY config for proper cert assignment.
   • DNS Pointing Wrong: id.ai’s A/CNAME record might resolve to ic0.app’s server, inheriting its cert.
   • No Cert for id.ai: The site lacks its own cert, so the server falls back to a default one (ic0.app’s).
3. Browser Enforcement: Chrome (and others) blocks with “not private” warning because the connection isn’t verifiable/encrypted for id.ai—risk of MITM attacks.
4. No Critical Errors in Cert Itself: Validity, chain (ISRG Root X1), and extensions are fine—no revocation or expiry issues. The problem is purely the name mismatch.

Impacts and Fixes

• Impacts: Site blocked (high bounce), no HTTPS (insecure data), SEO hits, trust loss.
• Quick Fixes:
  • Get a cert for id.ai via Let’s Encrypt (free, auto via Certbot)—add id.ai to SANs or issue separate.
  • Update server config to serve the right cert for id.ai (e.g., in Nginx: ssl_certificate /path/to/id.ai.crt;).
  • Test: Use ssllabs.com or browser dev tools (F12 > Security) post-fix.
  • If IC-hosted: Verify canister setup for custom domains—might need DFINITY’s cert manager.

If this is your site, start with cert issuance—should take <1 hour. Need help with steps or tools? Let me know!

[lmuntaner]

Good news,

The issue has been fixed!

[bitel911]

Great work, kudos for quick problem solving