I've filed a bug to track this misissuance and subsequent failure to report: https://bugzilla.mozilla.org/show_bug.cgi?id=1500593
On Fri, Oct 19, 2018 at 6:22 AM identrust--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Wednesday, October 17, 2018 at 9:08:41 PM UTC-4, Matt Palmer wrote: > > On Wed, Oct 17, 2018 at 03:09:52PM -0700, identrust--- via > dev-security-policy wrote: > > > On Tuesday, October 16, 2018 at 7:19:07 PM UTC-4, 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. > > > > > > IdenTrust:IdenTrust has strict procedures regarding issuance of > publicly > > > trusted website certificates. However at the time of this certificate > > > issuance (2015) the procedures did allow ability to request exceptions > for > > > IdenTrust internal deployments that were not accessible externally. > > > > On what date was this exception-requesting element added to IdenTrust's > > procedures? > > > > Please share the criteria which were used to evaluate exception requests. > > > > How many times has the procedure for requesting an exception been used? > How > > many times has the exception been granted? I think it would be best if > all > > certificates issued under this exception process were made public, to > ensure > > that there is full transparency around the extent to which this exception > > process was used. > > > > Finally, can you speak to why the BR requirements around internal names > and > > certificate expiry dates wasn't followed in this case? > > > > > However due to human error in implementation the server was made > available > > > external to our network. Also due to human error, the IT staff failed > to > > > request certificate revocation when the certificate was no longer > needed. > > > > Speaking of revocation, can you explain why this certificate wasn't > caught > > by the requirement to revoke all certificates containing internal names > by > > 2016-10-01? > > > > > Upon discovering of this misissuance on 02/22/2018, IdenTrust updated > the > > > website certificate approval procedures to eliminate the ability to > > > request exceptions to the standard domain validation\verification > > > procedures. Please note that these website issuance procedures apply > to > > > all applications regardless of the TLD(s) requested in the certificate > > > application. > > > > Correct me if I'm wrong, but does this mean that until the date you > > specified above, it was procedurally possible for IdenTrust to issue a > > certificate for *any* domain based on the invocation of this exception? > > Under which subsection of BR section 3.2.2.4 does IdenTrust believe this > > procedure was permitted as of the date of the procedure update? > > > > - Matt > IdenTrust: We acknowledge the request for more information and are > actively working on getting the necessary details to accurately respond. > We will respond as soon as we can. > > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
