2018. december 5., szerda 20:53:31 UTC+1 időpontban Gijs Kruitbosch a következőt írta: > On 05/12/2018 19:45, Wayne Thayer wrote: > > ..On Wed, Dec 5, 2018 at 1:58 PM dr. Sándor Szőke via dev-security-policy < > > [email protected]> wrote: > > 6./ > >> Explanation about how and why the mistakes were made or bugs introduced, > >> and how they avoided detection until now. > >> > >> Microsec manages the CISCO VPN cerver certificates separately from the TLS > >> certificates. The policy of the CISCO VPN servers was not changed when the > >> validity of the TLS certificates changed from 3 years to 2 years in March > >> 2018. > >> > > > > Why wasn't the policy for Cisco VPN servers updated? This points to a > > deeper failure to properly manage all of the profiles used to issue > > certificates that chain to publicly-trusted roots, and I would like to > > better understand what went wrong and how it will be prevented in the > > future? > > Adding some more questions on to this: does Microsec have any other > non-TLS cert policies that they "manage separately" from the TLS ones > (no matter how infrequently used), and if so how many, and have you > verified how any of those might qualify as TLS certs and thus fall under > the BR, and if so, that they abide by this validity BR? > > ~ Gijs
We can issue other certificates which are not TLS but they are similar. These are: Domain Controller certificates VPN server certificates In case of these certificates we use only the following EKUs: serverAuth (1.3.6.1.5.5.7.3.1) for both clientAuth (1.3.6.1.5.5.7.3.2) only for Domain controller These are absolutely conformant to the BR requirements, so there is no such a problem with them. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
