On Monday, October 17, 2016 at 4:19:34 PM UTC-7, Jakob Bohm wrote:
> On 16/10/2016 09:59, Adrian R. wrote:
> > Hello
> >
> > i read in the news (but not here on m.d.s.p) that a few days ago Globalsign
> > revoked one of their intermediary roots and then un-revoked it (well, the
> > revocation is accidental, but it was still a properly announced revocation,
> > via signed CRL and OCSP).
The official report is available here:
https://www.globalsign.com/en/customer-revocation-error/
To be clear, an intermediate root (not sure what this is tbh) was never revoked
- we revoked a cross certificate between roots R2 and R1 and an unused/EOL CA
under R2. These correctly appeared and continues to appear on the CRL, in fact
it was included on the October 7th Root R1 CRL well before the OCSP incident.
> >
> > http://www.theregister.co.uk/2016/10/15/globalsign_incident_report/
> >
> > They rolled back the revocation, but i thought that the BRs explicitly
> > forbid that a suspended/revoked certificate be un-suspended/un-revoked.
> >
> > https://www.globalsign.com/en/customer-revocation-error/
> >
> > is this revival/un-revocation of an intermediary CA allowed by the BRs?
> >
> I have just read that page, and find it utterly confusing and badly
> written. Lot's of formal tone of voice, but no precision or clarity.
>
> What I would have expected was a much clearer statement (on the page,
> not in some linked document) as to:
I hope my responses help clarify the situation:
> 1. Which Intermediary CA certificates were affected (because
>certificate holders cannot see the cache state affecting relying
>parties, we need to check our certificates against something
>specific to see if we are affected).
All CAs under Root R1 were effected.
> 2. If this affects all AlphaSSL and CloudSSL certificates or only some
>of them.
This affects the CAs under Root R1 only (AlphaSSL, DV, OV, CloudSSL). None of
the actual end entity SSL certificates were ever revoked or marked as revoked
either via CRL or OCSP. The scope of the users impacted by this depends on
many factors, which are outlined in the report. Not all users were blocked
from accessing sites with SSL certificates under R1.
> 3. If this was an "exercise" (training/experimental etc.) or an actual
>operational decision.
We intentionally revoked 2 CA certificates as listed in the incident report -
One old CA that had no live certificates issued under it, and the one cross
certificate referenced above.
We did not take actions to revoke any CAs other than these two; however as
pointed out, the OCSP responders incorrectly created and provided OCSP status
messages for CAs under R1 indicating that the CA was revoked. These CAs never
appeared in any CRLs.
> 4. If the revoked cross certificate was one of the cross certificates
>previously provided to certificate holders to allow us to make our
>servers compatible with older clients, and if so, which one.
> 5. If this was e-mailed to all potentially affected certificate
>holders, or just dumped in some public forums which certificate
>holders might not see in time to take necessary action.
GlobalSign contacted as many of our customers as possible with SSL certificates
issued under Root R1. Note that EV certificates are issued under Root R2 and
were not impacted by this issue.
>
> 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
