> This unfortunately had the issues summarized in David's email above. A > certificate has signed and unsigned parts, meaning it can be modified so > different fingerprints can refer to the same certificate, and a renewed > certificate will have a different fingerprint by design. But that's not a problem in this case. We are only talking about using the full sha1 in the UI for comparison with what the sysadmin wrote on a post-it note, or what Firefox on a different machine shows in its certificate info UI after it accepted the cert properly through the CA that *is* installed there (remember, Kevin's focus is Android where installing a new CA is a PITA and now seems to produce constant "reminders" that your device is insecure and can be MITM-ed). We are still going to actually *store* the new pubkey hash, and use that for later connections. > Wouldn't it help to get the new key fingerprint using a command of > openconnect? Not sure. You might not even have openconnect on the machine that can verify the cert. >> So maybe we need a new library function to return the old >> (standardized) hash, and once that is accepted through the UI, cache >> the pubkey hash and use that for future comparisons? > > That would certainly be possible, but will lead to more confusion than > solving. Some programs will be using the old hash and others the new > defeating the purpose of a fingerprint. No, the old hash should only ever be used by the *user* in the case that the happen to have a sha1 obtained by other out-of-band means. Just putting it into the textual output of the openconnect_get_peer_cert_details() function would almost suffice, except that Kevin didn't want to show his users that whole thing. -- dwmw2
