Revision history [back]

This is a suggestion for handling self-signed and optionally (via a setting in UI) also other certificate acceptance.

Nowadays web browser, mail applications and mobile platforms in general have too many CA certificates enabled and make it too hard to install or accept self-signed certificates even if these would be more secure to be used than the public well-known CA signed certificates. Some of these issues can be solved with builtin certificate manager (See: https://together.jolla.com/question/11198/certificate-manager/ ), but it is useful to provide user a way to accept server certificates also while using the device.

The suggested process follows the SSH style acceptance of the host key:

1. App or network configuration encounters a new certificate.
2. The certificate information is retrieved and checked if the certificate is signed by any of the trusted CAs in platform certificate store.
3. If it is, trust information (is it signed, what are the current trust settings for CA etc.) is communicated to user (this could be optional, but so that user could configure all certificates to need to be accepted). The user may in this case make changes to either the CA certificate (for example to accept CA to be trusted to verify certificates for this purpose) or accept the certificate for this purpose and this purpose only. Purpose meaning that accepting certificate for web browsing would not accept it for mail connections or WiFi authentication by default -- only for that purpose or even for only that app.
4. If the certificate is not signed by any of trusted CAs or otherwise trusted for this purpose, the infromation about this with suitable warnings should be given to user. In this case the user would be now able to accept this certificate to be trusted for the purpose where it was encountered (wifi, email, web). The user may be able to extend the trust for certain certificate directly to all those things, but this should be an advanced option.
5. The certificate trust information would be stored in the system certificate store and be modifiable via certificate manager.
6. When the same self-signed certificate would be encountered again in the same purpose, the certificate validity and possible change in certificate would be detected.
7. If the certificate had changed/expired/etc., a warning for user would be communicated with the possibility of accepting or denying connection and/or certificate. In this case user should have also an advanced option to add the certificate to certificate blacklist so that when it was offered once again, the connection and dialog to accept it would not be offered ever (or suitable long time) again (without removing certificate from the blacklist).

This process is not polished (written in one evening when I had time) and there probably exist better and more accurate description of it in the Internet (IETF etc.). There also exists alternative ways to verify certificates for example via IPSEC like DANE (http://www.internetsociety.org/articles/dane-taking-tls-authentication-next-level-using-dnssec), which could be used for the purpose, but as DNSSEC and trust router infrastructure are not there yet, a reasonably good way to handle self-signed certificates would help until better can be used.

Feel free to comment this suggestion, point out possible security flaws in it and improve it.

This is a suggestion for handling self-signed and optionally (via a setting in UI) also other certificate acceptance.

Nowadays web browser, mail applications and mobile platforms in general have too many CA certificates enabled and make it too hard to install or accept self-signed certificates even if these would be more secure to be used than the public well-known CA signed certificates. Some of these issues can be solved with builtin certificate manager (See: https://together.jolla.com/question/11198/certificate-manager/ ), but it is useful to provide user a way to accept server certificates also while using the device.

The suggested process follows the SSH style acceptance of the host key:

1. App or network configuration encounters a new certificate.
2. The certificate information is retrieved and checked if the certificate is signed by any of the trusted CAs in platform certificate store.
3. If it is, trust information (is it signed, what are the current trust settings for CA etc.) is communicated to user (this could be optional, but so that user could configure all certificates to need to be accepted). The user may in this case make changes to either the CA certificate (for example to accept CA to be trusted to verify certificates for this purpose) or accept the certificate for this purpose and this purpose only. Purpose meaning that accepting certificate for web browsing would not accept it for mail connections or WiFi authentication by default -- only for that purpose or even for only that app.
4. If the certificate is not signed by any of trusted CAs or otherwise trusted for this purpose, the infromation about this with suitable warnings should be given to user. In this case the user would be now able to accept this certificate to be trusted for the purpose where it was encountered (wifi, email, web). The user may be able to extend the trust for certain certificate directly to all those things, but this should be an advanced option.
5. The certificate trust information would be stored in the system certificate store and be modifiable via certificate manager.
6. When the same self-signed certificate would be encountered again in the same purpose, the certificate validity and possible change in certificate would be detected.
7. If the certificate had changed/expired/etc., a warning for user would be communicated with the possibility of accepting or denying connection and/or certificate. In this case user should have also an advanced option to add the certificate to certificate blacklist so that when it was offered once again, the connection and dialog to accept it would not be offered ever (or suitable long time) again (without removing certificate from the blacklist).

This process is not polished (written in one evening when I had time) and there probably exist better and more accurate description of it in the Internet (IETF etc.). There also exists alternative ways to verify certificates for example via IPSEC like DANE (http://www.internetsociety.org/articles/dane-taking-tls-authentication-next-level-using-dnssec), which could be used for the purpose, but as DNSSEC and trust router infrastructure are not there yet, a reasonably good way to handle self-signed certificates would help until better can be used.

Feel free to comment this suggestion, point out possible security flaws in it and improve it.

This is a suggestion for handling self-signed and optionally (via a setting in UI) also other certificate acceptance.

Nowadays web browser, mail applications and mobile platforms in general have too many CA certificates enabled and make it too hard to install or accept self-signed certificates even if these would be more secure to be used than the public well-known CA signed certificates. Some of these issues can be solved with builtin certificate manager (See: https://together.jolla.com/question/11198/certificate-manager/ ), but it is useful to provide user a way to accept server certificates also while using the device.

The suggested process follows the SSH style acceptance of the host key:

1. App or network configuration encounters a new certificate.
2. The certificate information is retrieved and checked if the certificate is signed by any of the trusted CAs in platform certificate store.
3. If it is, trust information (is it signed, what are the current trust settings for CA etc.) is communicated to user (this could be optional, but so that user could configure all certificates to need to be accepted). The user may in this case make changes to either the CA certificate (for example to accept CA to be trusted to verify certificates for this purpose) or accept the certificate for this purpose and this purpose only. Purpose meaning that accepting certificate for web browsing would not accept it for mail connections or WiFi authentication by default -- only for that purpose or even for only that app.
4. If the certificate is not signed by any of trusted CAs or otherwise trusted for this purpose, the infromation about this with suitable warnings should be given to user. In this case the user would be now able to accept this certificate to be trusted for the purpose where it was encountered (wifi, email, web). The user may be able to extend the trust for certain certificate directly to all those things, but this should be an advanced option.
5. The certificate trust information would be stored in the system certificate store and be modifiable via certificate manager.
6. When the same self-signed certificate would be encountered again in the same purpose, the certificate validity and possible change in certificate would be detected.
7. If the certificate had changed/expired/etc., a warning for user would be communicated with the possibility of accepting or denying connection and/or certificate. In this case user should have also an advanced option to add the certificate to certificate blacklist so that when it was offered once again, the connection and dialog to accept it would not be offered ever (or suitable long time) again (without removing certificate from the blacklist).

This process is not polished (written in one evening when I had time) and there probably exist better and more accurate description of it in the Internet (IETF etc.). There also exists alternative ways to verify certificates for example via IPSEC DNSSEC like DANE (http://www.internetsociety.org/articles/dane-taking-tls-authentication-next-level-using-dnssec), which could be used for the purpose, but as DNSSEC and trust router infrastructure are not there yet, a reasonably good way to handle self-signed certificates would help until better can be used.

Feel free to comment this suggestion, point out possible security flaws in it and improve it.