So while I see no https traffic on the system, I do see regular http traffic, and reloading apache for the https change will affect those downloads.

When there is no traffic, the following patchset can be merged:

https://gerrit.wikimedia.org/r/#/c/188492/

Then, once it is live on palladium, someone can rm the file /etc/ssl/certs/dumps.wikimedia.org.chained.pem and then run puppet. Once puppet runs, reloading apache should show the new certificate.

Also, Once this is completed, we need to revoke the SHA1 cert. So someone can do this via rapidssl, or I'll do so once the other ticket is live.

(Anyone can push this change live when they notice there is no http/https traffic on ms1001. You can check with the following commands:

netstat | grep http
netstat | grep https

followed my own advice, and the one http connection that wasnt a crawler or neon just died, so pushing now.

so the cert is in the filesystem on ms1001, but isnt serving it. ive restarted and reloaded nginx, so not sure whats up. I'll keep hacking at it, but usability isnt gone, just still shows SHA1 cert.

This changeset (https://gerrit.wikimedia.org/r/#/c/189493/) will, after the old /etc/ssl/localcerts/dumps.wikimedia.org.chained.crt is moved out of the way, force the generation of a new one. Verified on ms1001. However nginx does not start up with the new crt file because the old private key is still being used (where is the new one? I don't see it in the private repo.) I have put the old crt file back in place for now.

It is the same private key, no change.

Hrmm, that change is correct, and this should work. Let me loop back to this shortly.