Locally extending trusted certificates

[Tyler Hicks]

On 01/18/2017 07:00 PM, Manik Taneja wrote:
> hi there,
> 
> just wanted to follow-up on this query and see if we have a solution to
> this problem?

There have been some offline discussions about possible solutions but
they're still in the early stages and nobody is actively work on this
right now.

Loïc's request of allowing the admin to extend the set of system-wide
trusted certs is the most useful/common use case of extending the system
certs. I think the first step would be to fully design option #1 or
think through the basic requirements for snapd to manage adding/deleting
certs specified by the admin (a simpler version of #2).

Tyler

> /manik
> 
> On Fri, Jan 6, 2017 at 9:17 AM, Loïc Minier <loic.minier at ubuntu.com
> <mailto:loic.minier at ubuntu.com>> wrote:
> 
>     Hi,
> 
>     This question came up in the context of Docker registries with
>     self-signed certificates:
>     http://askubuntu.com/questions/868268/add-self-signed-certificate-in-ubuntu-core-16-04
>     <http://askubuntu.com/questions/868268/add-self-signed-certificate-in-ubuntu-core-16-04>
>     this could be addressed in ways specific to the Docker snap, but I
>     believe this touches a larger question: support for extending the
>     list of system-trusted certificates.
> 
>     Our Ubuntu Core images ship with a set of trusted certificates.
>     These are inherited from the .deb world where there is a mechanism
>     to locally extend the list of trusted certificates
>     (update-ca-certificates). This mechanism doesn't work with core
>     images due to read-only directories (and perhaps other issues as well).
> 
>     Here are some possible options to address this:
>     1) fix the update-ca-certificates system to also work on core
>     images; this might just be a matter of making some directories
>     bind-mounts to the writable space
> 
>     2) implement some kind of snapd keystore feature/configs/APIs (much
>     like system keystores on mobile OSes); this is likely significant
>     work, but opens interesting perspectives in providing new management
>     APIs and a more secure implementation. For instance, one could
>     design this to store secrets in hw-specific secure stores, or offer
>     mechanisms to roll out new certificates/keys via assertions, or to
>     disable some specific CAs
> 
>     3) keep the list of system certificates as static and not locally
>     configurable; this will likely result in some snaps developing
>     alternate keystores
> 
>     I'm sure there are other options and I'd to hear how people think
>     this should best be addressed in the snap/snapd world.
> 
>     Cheers,
>     - Loïc Minier
> 
>     --
>     Snapcraft mailing list
>     Snapcraft at lists.snapcraft.io <mailto:Snapcraft at lists.snapcraft.io>
>     Modify settings or unsubscribe at:
>     https://lists.ubuntu.com/mailman/listinfo/snapcraft
>     <https://lists.ubuntu.com/mailman/listinfo/snapcraft>
> 
> 
> 
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/snapcraft/attachments/20170119/30af2f16/attachment.sig>