Do the Three Faymas Domains Share One TLS Certificate? Four Certs, Zero Shared Names

No. On 14 November 2026 we opened TLS connections to the three faymas domains plus one subdomain and read the certificates they actually presented. We got four different certificates. Each has its own serial number, its own issue date and its own list of covered names. The intersection of the three apex certificates' name lists is empty: not one hostname appears on more than one of them. They do share an issuer, a key algorithm, a cipher and a Cloudflare edge. Sharing the machinery is not sharing the certificate.

Updated November 14, 2026 · Network identity measurement

This guide reports TLS certificate and DNS answers seen from one machine on 14 November 2026. It does not examine origin servers, accounts, registrant records or ownership.

What was measured, and what was not

Four hosts got three repeats each. openssl s_client connected on port 443 with SNI set to the hostname, and the leaf certificate was parsed out of the returned chain. Subject, issuer, serial, validity dates, subject alternative names, public-key algorithm, signature algorithm and chain length came from openssl x509. DNS answers came from nslookup. HTTP status, redirect target, edge IP and CF-RAY came from curl. Every certificate fetch returned byte-identical certificate fields on all three attempts.

The four certificates are the ones for faymas.in, faymas.net, faymas-in.com and cdn.faymas.in. Two more hostnames, www.faymas.in and www.faymas.net, were also probed. Both presented the same certificate as their apex, so they add hosts but not certificates.

Limits. One machine. One recursive resolver. One half-hour on one day. DNS answers are what that resolver returned, not a global view. We did not query registrant records, we did not inspect certificate transparency logs, and we did not reach any origin server behind the edge. A certificate proves that someone controlling the zone satisfied a CA challenge at issuance. It does not name a person, a company or an owner.

Four certificates, four serials

Read the serials first. They are all different. Then read the dates: four different issue dates, spread from late September to early November. Each window is exactly ninety days long.

All four were issued by C=US, O=Google Trust Services, CN=WE1. All four carry a three-certificate chain. All four use ECDSA P-256 keys with ecdsa-with-SHA256 signatures. A default handshake negotiated TLS 1.3 with TLS_AES_256_GCM_SHA384; a forced TLS 1.2 handshake also succeeded on all four, with ECDHE-ECDSA-CHACHA20-POLY1305. Identical cryptography down to the cipher.

So the pipeline is shared. The outputs are not. A single automated issuer, producing separate certificates on separate schedules, is the simplest reading of this table. It is a reading, not a proof: we watched the certificates, not the issuance system.

The names each certificate covers

A certificate's subject alternative name list is the exact set of hostnames it is valid for. Here are all four lists, verbatim.

Two of the three apex certificates wildcard the whole zone. The third does something different. faymas.net lists *.www.faymas.net, not *.faymas.net. Its wildcard starts one level deeper, beneath the www label. A name such as assets.faymas.net would not be covered by this certificate, while assets.faymas.in would be covered by *.faymas.in. That is a direct consequence of the strings above, not a guess about intent.

The lists do not overlap. Not one DNS name appears on two of the four certificates. Even the cdn.faymas.in certificate, which belongs to the faymas.in zone, names its own host plus a Cloudflare SNI placeholder instead of reusing the apex list.

Three www policies, one CDN

The apex and www hosts do not behave the same way on the three domains. We asked each pair for its root URL and its DNS name.

One domain sends www back to the apex. One sends the apex to www. One has no www at all. Three different canonical-host decisions, all behind the same edge provider.

The third row is the interesting one. faymas-in.com holds a wildcard certificate for *.faymas-in.com, so www.faymas-in.com is a name the certificate would happily validate. But the DNS answer for that name is NXDOMAIN with zero answer records, returned by norman.ns.cloudflare.com. Three lookups agreed. A covered name with no address is still unreachable. Certificate coverage and DNS existence are two separate switches, and here only one is on.

The subdomain with a wildcard it does not use

cdn.faymas.in resolves to 104.21.7.105 and 172.67.155.118 — the exact pair that faymas.in resolves to. Its name sits inside *.faymas.in, the wildcard on the apex certificate. Nothing about the name requires a second certificate.

It gets one anyway. The certificate served on cdn.faymas.in has subject 26f224e6.sni.cloudflaressl.com, a different serial, and an issue date of 9 November — seven days after the apex certificate's 2 November. Its SAN list names the SNI placeholder and cdn.faymas.in only. A request to its root returned 404 with a Cloudflare cache HIT.

That is the cleanest original finding in this set. A wildcard in a SAN list is a capability, not a promise about which certificate a host will present. Checking the apex certificate and concluding "the subdomain is covered" would have been wrong in a way that only a direct connection to the subdomain reveals.

One issuing pipeline, three separate zones

Put the layers side by side. At the cryptographic layer everything matches: one issuer, one key type, one signature algorithm, one TLS 1.3 cipher, one chain length, one TLS 1.2 fallback cipher. At the edge layer everything matches too. All successful responses carried Server: cloudflare, and every CF-RAY in this run ended in -NRT. The three apex domains each resolve to two addresses drawn from the same 104.21.x.x and 172.67.x.x ranges, though no single address is shared between any two apex domains.

At the zone layer nothing matches. Six different Cloudflare nameserver hostnames across the three domains, with zero overlap: novalee and rudy for faymas.in, brenda and lamar for faymas.net, norman and priscilla for faymas-in.com. Four serials. Four issue dates. Four SAN lists. Three different www policies.

Distinct nameserver pairs and distinct certificates are consistent with separately provisioned zones. That is as far as the data goes. Shared edge addresses prove that the same CDN answered our requests. They say nothing about who holds the accounts, who pays for them, or where the origin servers sit. Anyone who tells you otherwise is reading an IP address as a signature.

What to check next

These four certificates are on a clock. From 14 November 2026, faymas.net has 40 days left, faymas-in.com 69, faymas.in 78 and cdn.faymas.in 85. The .net certificate expires first, on 24 December 2026.

That gives a cheap, falsifiable test. Reconnect in January. If the four serials have changed and the windows have shifted forward by roughly ninety days, the rotation is automated and nobody is watching it. If the .net serial is still 540AA48CC53E8D8E13E882D5C2D3B219 after 24 December, something is being served that should have been replaced. Either outcome is a fact you can collect in one handshake. No ranking data, no traffic estimate, no guess about the business — just a date and a serial number.

FAQ

Do the three faymas domains share a TLS certificate?

No. On 14 November 2026 the three apex hosts presented three certificates with three different serial numbers, and the probe of cdn.faymas.in produced a fourth. The intersection of the three apex SAN lists is empty.

Who issued the faymas TLS certificates?

All four were issued by Google Trust Services under the WE1 intermediate, with three-certificate chains, ECDSA P-256 keys and ecdsa-with-SHA256 signatures. Each is valid for exactly ninety days. A default handshake used TLS 1.3; TLS 1.2 was also accepted on all four.

Does the faymas.net certificate cover its subdomains?

Only those under www. Its SAN list is faymas.net, www.faymas.net and *.www.faymas.net, so the wildcard starts one level deeper than the *.faymas.in and *.faymas-in.com wildcards on the other two domains.

Why does cdn.faymas.in have its own certificate?

We can report that it does, not why. It sits inside the *.faymas.in wildcard, yet presents a separate SNI certificate with subject 26f224e6.sni.cloudflaressl.com, its own serial and an issue date seven days later. The reason for that provisioning choice is not visible from the outside.

Does a wildcard certificate mean the hostname exists?

No. The *.faymas-in.com wildcard would validate www.faymas-in.com, but three DNS lookups for that name returned NXDOMAIN with zero answer records, and no TLS connection could be made.