[Acme] looking for prior-art for "deploying" certificates to virtual machines

[Michael Richardson <[e-mail]>]

There are lots of things out there about fTPMs for HyperV or ESX hosted VMs,
(long in howto, short on details, alas),  and many bits and pieces of documentation on
cloud-init, particularly for installing root/.ssh/authorized_keys, but
nothing specific I've found about deploying certificates to virtual machine appliances.
It is clear that one could do this via cloud-init, but that there doesn't
seem to be any kind of standard.

Here is the scenario that I want to support:

1) user, aka IT administrator, downloads a vmdk/ova/qcow2 from the Internet.
   {or: selects EC2 AMI from palette in amazon VM store}

2) image is deployed on VM infrastructure, including, in particular, they
   could just boot it up on their desktop using VM Workstation, VirtualBox,
   virtmanager, or kvm -hda foo.qcow2.

3) rocker switch is put into MoreMagic<tm> setting
    {  http://www.catb.org/jargon/html/magic-story.html }

4) VM boots up in bridged mode on the "LAN", and announces itself as "myawesomevm.local"
   http://myawesomevm.local, 301 redirect to https://myawesomevm-abcd4.cooldomain.com/
   and happy admin continue doing MyAwsomeVM stuff via web browser.

The IoTSF ManySecureWG has some ideas on how to make the https:// URL work
for nicely. Christian Amsuess re-discovered a trick that seems to have been
first done by https://blog.filippo.io/how-plex-is-doing-https-for-all-its-users/

Doing dns-01 challenges with a manufacturer is also an easy way to bootstrap
into the above mentioned mechanism, and I wrote that up in an ID
  https://datatracker.ietf.org/doc/draft-richardson-homerouter-provisioning/

But, while these things explain how we get end-browser trust with the device,
what it doesn't do is explain how this new VM is considered legitimate by
whatever manager/author created it.

There are some options:

1) a common keypair is built-in to the VM when the image is created.  That
   is, every single VM has the same private key.  This is used to
   "authenticate" some kind of enrollment with provisioning system.
   Such a "secret" is not really very secret, as really anyone can take the
   VM apart.
   (Sure, EC2 has some controls on who can get the AMI to take it apart.
   But, in general private cloud owners can and should look into the VMs they
   are running)

2) via cloud-init with some kind of secret provided out-of-band.
   I note that cloud-init can take things from ISO images, so the person
   downloading could actually download an ova file *as well* as some .iso
   image that they attach when booting.
   It seems that that this will work for "workstation" environments, but
   it seems tedious for the less clueful admins.

3) by having some dialog on the "console" where the virtual appliance
   perhaps calls home, and the administrator enters some token on that they
   got via some other interface (a registration web interface).
   This is commonly done for installation of license keys today, and in the
   past I've automated things for installation on physical machines.
   This could also work for EC2/Linode/DigitalOpen, if done by SSH.


How is this really ACME related?
Well, the goal is to finish by deploying an https certificate on the device.

How is this really ANIMA related? Well, for me, this VM is either (a) new Registrar,
(b) a virtual appliance as a Pledge, and so needs that IDevID.

My ideal situation would be that someone would tell me that there is this
standard in industry association AbscurelyBootedComputers which has convinced
all the parties that this problem needs to be solved, and I can just "apt-get
install kvm-abc" and I'd be done.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [