<story><title>Subdomain.center – discover all subdomains for a domain</title><url>https://www.subdomain.center/</url></story><parent_chain><item><author>paranoidrobot</author><text>Adding CAs to trust stores on devices and in apps is a major pain.&lt;p&gt;If you have unmanaged devices this becomes even more painful.&lt;p&gt;&amp;quot;Oh, hi, welcome to the company, please install this Root CA onto your machine to access &amp;lt;internal service&amp;gt;&amp;quot;&lt;p&gt;Because you can&amp;#x27;t scope CAs to specific domains, this causes everyone with any idea about security to start being concerned.</text></item><item><author>proto_lambda</author><text>If the subdomains aren&amp;#x27;t supposed to be public, the public also doesn&amp;#x27;t need to trust the TLS certs. Sign them with your own CA and trust it on the devices that should be able to access the domains.</text></item><item><author>TekMol</author><text>That&amp;#x27;s why HTTPS is still a pain in the butt. 30 years after it was invented.&lt;p&gt;I don&amp;#x27;t want internally used subdomains to be public. Because of certificate transparency, the only way to achieve that is via wildcard certs.&lt;p&gt;Let&amp;#x27;s encrypt only supports cumbersome validation methods for those. Like changing DNS records every time you need to renew the cert.&lt;p&gt;Pretty annoying.</text></item><item><author>Brananarchy</author><text>As others have said, certificate transparency seems to be doing some heavy lifting here. It reports subdomains for me that have never had a public CNAME or A record, but have had let&amp;#x27;s encrypt certs issued for internal use.&lt;p&gt;It&amp;#x27;s also missing some that have not had certs issued, but that are in public DNS</text></item></parent_chain><comment><author>layer8</author><text>Where I work, having internal services be accessed by employees’ own, unmanaged devices would be a no-go anyway. It would be considered a huge security loophole.</text></comment>
<story><title>Subdomain.center – discover all subdomains for a domain</title><url>https://www.subdomain.center/</url></story><parent_chain><item><author>paranoidrobot</author><text>Adding CAs to trust stores on devices and in apps is a major pain.&lt;p&gt;If you have unmanaged devices this becomes even more painful.&lt;p&gt;&amp;quot;Oh, hi, welcome to the company, please install this Root CA onto your machine to access &amp;lt;internal service&amp;gt;&amp;quot;&lt;p&gt;Because you can&amp;#x27;t scope CAs to specific domains, this causes everyone with any idea about security to start being concerned.</text></item><item><author>proto_lambda</author><text>If the subdomains aren&amp;#x27;t supposed to be public, the public also doesn&amp;#x27;t need to trust the TLS certs. Sign them with your own CA and trust it on the devices that should be able to access the domains.</text></item><item><author>TekMol</author><text>That&amp;#x27;s why HTTPS is still a pain in the butt. 30 years after it was invented.&lt;p&gt;I don&amp;#x27;t want internally used subdomains to be public. Because of certificate transparency, the only way to achieve that is via wildcard certs.&lt;p&gt;Let&amp;#x27;s encrypt only supports cumbersome validation methods for those. Like changing DNS records every time you need to renew the cert.&lt;p&gt;Pretty annoying.</text></item><item><author>Brananarchy</author><text>As others have said, certificate transparency seems to be doing some heavy lifting here. It reports subdomains for me that have never had a public CNAME or A record, but have had let&amp;#x27;s encrypt certs issued for internal use.&lt;p&gt;It&amp;#x27;s also missing some that have not had certs issued, but that are in public DNS</text></item></parent_chain><comment><author>bostik</author><text>As sibling poster already wrote, technically you &lt;i&gt;can&lt;/i&gt; scope a CA to a set of subdomains only. Or try. The spec entry is &amp;quot;nameConstraints&amp;quot; but for a number of reasons it may not be well supported.&lt;p&gt;Some of those reasons are absolutely hilarious. I needed to set up an internal CA back in 2015, and wanted to limit the blast radius in case the private key was leaked. (Usually a &amp;quot;when&amp;quot;, not &amp;quot;if&amp;quot; scenario.) I learned about the nameConstraints field and tried to use it. OpenSSL would ignore the key in a CSR input file. Okay, fine, the spec has an OID for the field so I reached for the nearest ASN.1 library to construct a modified CSR with the field in place.&lt;p&gt;OpenSSL broke trying to parse the file. Go&amp;#x27;s implementation blew up with a magnificent trace. I gave up and the internal CA was generated with a global validity scope.&lt;p&gt;I later learned that apparently Microsoft&amp;#x27;s PKI libraries had support for scope limits, but the feature was not used in real life. Likely because if such a thing came into contact with anything else in the wild, the underlying libraries would just implode.&lt;p&gt;If you had a self-signed client cert with a nameConstraints in the supplied CA chain, you could probably still crash a non-trivial fraction of web servers.</text></comment>