-
Dan Williams authored
First, it was not easily possible to set a private key without also providing a password. This used to be OK, but now with secret flags it may be the case that when the connection is read, there's no private key password. So functions that set the private key must account for NULL passwords. Unfortunately, the crytpo code did not handle this case well. We need to be able to independently (a) verify that a file looks like a certificate or private key and (b) that a given password decrypts a private key. Previously the crypto code would fail to verify the file when the password was NULL. So this change fixes up the crytpo code for a more distinct split between these two operations, such that if no password is given, the file is still checked to ensure that it's a private key or a certificate. If a password is given, the password is checked against the private key file. This commit also changes how private keys and certificates were handled with the BLOB scheme. Previously only the first certificate or first private key was included in the property data, while now the entire file is encoded in the data. This is intended to fix cases where multiple private keys or certificates are present in a PEM file. It also allows clients to push certificate data to NetworkManager for storage in system settings locations, which was not as flexible before when only part of the certificate or key was sent as the data.
28e6523b