If the old certificate was not compromised, it is a lot cleaner to simply let it expire. Revokcation, as I understanding it, will require that we populate the revocation listings, which is non-optimal if there hasn't been a compromise.

@BBlack can explain this far more elequently than I can, since he was the one who initially explained it to me when I was going to revoke a certificate in a similar state (not compromised, simply no longer used.)

@Jgreen: I don't want to simply call this resolved, since its your task and your call. I'd advise though we just let the old cert expire normally though, and not revoke.

I think in this case we should revoke unless the expiry is already very close (it might be!). This is private key that is out of our control, and I honestly don't even understand all the machinations of the change of vendors involved here. It was one thing to trust them to represent one of our hostnames in a TLS public key when they were an active vendor with a contractual relationship, it's another to trust that that key is still secure in the aftermath of that relationship ending.

Ah I missed the part above where it stated that it expired in a week or two. In that case, there's little point for this particular certificate.

Looks like it expires in September:

Validity
    Not Before: Jul 18 18:16:03 2016 GMT
    Not After : Sep  4 12:10:02 2017 GMT
Subject: C = US, ST = California, L = San Francisco, O = "Wikimedia Foundation, Inc.", CN = eventdonations.wikimedia.org

I only advised against revokcation since that was my understanding from @BBlack, I'm not trying to block this. In fact, I can go ahead and revoke if everyone thinks best!

Change 364468 had a related patch set uploaded (by RobH; owner: RobH):
[operations/puppet@production] remove eventdonations.w.o cert from repo

https://gerrit.wikimedia.org/r/364468

Change 364468 merged by RobH:
[operations/puppet@production] remove eventdonations.w.o cert from repo

https://gerrit.wikimedia.org/r/364468