Marius Bakke <mba...@fastmail.com> skribis: > Ludovic Courtès <l...@gnu.org> writes: > >> Marius Bakke <mba...@fastmail.com> skribis:
[...] >>> If the private key used on https://git.savannah.gnu.org/ is static, one >>> option would be to "pin" the corresponding public key. However, some LE >>> clients also rotate the private key when renewing, so we'd need to ask >>> SV admins. And also receive notices in advance if the key ever changes. >>> >>> Pinning the intermediate CAs might work, but what to do when the >>> certificate is signed by a new intermediate (which may happen[0])? How >>> to deliver updates to users with old certs? >>> >>> See: https://www.owasp.org/index.php/Pinning_Cheat_Sheet and >>> https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning >>> >>> ..for quick and long introductions, respectively. >>> >>> [0] >>> https://community.letsencrypt.org/t/hpkp-best-practices-if-you-choose-to-implement/4625?source_topic_id=2450 >> >> All good points. Well, I guess there’s not much we can do? > > I think pinning the public key could work, if the Savannah > administrators are aware of it. But we'd need a reliable fallback > mechanism in case the private key needs to be updated. Yeah, sounds fragile. > I think having a separate 'le-certs' package that can verify the Lets > Encrypt chain sounds like the easiest option. Presumably new > intermediates etc will be known well in advance. That sounds more reasonable to me. Do you know what it would take to get the whole LE chain in such a package? Would you like to give it a try? Thanks, Ludo’.
