We have cpsec running since we are using RAP5 as campus AP and performing bridging on the wired ports so cpsec was required to be enabled.
Supposedly cpsec data can be shared among master-locals - so failover from local to master should not require certificate re-installation.
We run all stand-alone masters so I can't confirm - Master clustering does should alleviate this, but doesn't work in 6.1.x - should be fixed in 6.2.x - but I have not verified (running 6.1.3.7 as well)
I think all 802.11n AP have a built-in cert and can be trusted on the controller and install the switch cert - reboot and come up on another controller - but the older AP's (AP70's for me and I suspect AP65's for you will act similar) do not have a built-in cert - so they install the cert of the first controller they come up on - but this cert will not be trusted by another controller - so if these AP's failover they do not recover automatically)
you can look AP stuck in this state with the following command:
# show whitelist-db cpsec | include hold,unapproved
if you find any AP's in this state - delete them from the whitellist-db - the AP's will dump their current cert - reboot and install the cert of the next controller they talk to:
whitelist-db cpsec del mac-address $mac
I created a perl expect scritp to walk my controllers periodically and delete any stuck AP's - thankfully I think I'm down to only a handful of AP70's left on the network