On 17/10/2018 01:18, Matt Palmer wrote:
On Tue, Oct 16, 2018 at 02:18:39PM -0700, identrust--- via dev-security-policy
wrote:
5.Explanation about how and why the mistakes were made, and not caught and
fixed earlier.
IdenTrust: The certificate was generated for a server within IdenTrust.
The certificate contained internal domain names which were not reachable
externally. Two domain names in the SAN (Autodiscover.identrus.int and
Mercury.identrus.int) were included at that time. When the certificate
was generated, these domains were internally hosted domains.
This doesn't explain why the mistakes were made, nor does it explain why
they were not caught and fixed earlier.
6. List of steps your CA is taking to resolve the situation and ensure
such issuance will not be repeated in the future, accompanied with a
timeline of when your CA expects to accomplish these things.
IdenTrust: Post 02/22/2018, IdenTrust implemented a change in the
certificate approval processes that will prevent the domain names with the
.int TLD from being approved.
What about other non-existent TLDs?
- Matt
And what about real domains in the very existant .int domain (in case
one of those requests an Identrust certificate).
..int contains almost exclusively high value domains such as un.int,
nato.int etc.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
