After deploying the Apache CRL check setting to address T184444 several hosts have been found in an unusual state where:
- a signed certificate is present on the agent/server and...
- the certificate has not been revoked but...
- the signed certificate is not present on the puppet master
Normally this could be addressed simply by generating and signing new certificates, but this is complicated by the fact that systems are exposing (via base::expose_puppet_certs) their puppet certificates for use in other applications.
Below are systems exposing their puppet cert/key for use in other applications. Let's review each for impact and potential issues before proceeding with generating/signing new puppet certs.
(check off after new puppet cert has been generated and signed)
- cp1052.eqiad.wmnet - decommissioned T208584
- es2014.codfw.wmnet - decommissioned T262889
- ganeti2001.codfw.wmnet
- ms-be2021.codfw.wmnet - decommissioned T272837
- mw2105.codfw.wmnet - decommissioned (cant find task)
- mw2121.codfw.wmnet - decommissioned T189111
- mw2131.codfw.wmnet - decommissioned T189111
- mw2132.codfw.wmnet - decommissioned T189111
- mw2144.codfw.wmnet - decommissioned T261524
- mw2191.codfw.wmnet - decommissioned T261524
- mw2193.codfw.wmnet - decommissioned T261524
- mw2206.codfw.wmnet - decommissioned T261524
- mw2229.codfw.wmnet - decommissioned T277119
- mw2231.codfw.wmnet - decommissioned T277119
- mw2240.codfw.wmnet - decommissioned T277119
- rdb2002.codfw.wmnet - decommissioned T209425
- wtp2005.codfw.wmnet
- wtp2020.codfw.wmnet