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

From: Michael Richardson <[email-masked]>
Date: Sat, 22 May 2021 17:23:59 -0400

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   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 23 May 2021 14:11:53 +0000

Have you looked at what cloud providers do?

---

From: Michael Richardson <[email-masked]>
Date: Mon, 24 May 2021 16:07:35 -0400

> Have you looked at what cloud providers do?

Yes.  Perhaps you saw the references to "cloud-init", which has more than a
handful of different ways of getting data from the virtualization environment
into the VM: virtual CDroms, magic variables, http://169.254.254.254/ URLs,
etc.

As far as I can tell, none of them provide for a *certificate* suitable for
TLS to be returned.    There is no (defacto-) standard way to do ACME or EST or CMP via
some channel.   I'd love to be wrong.

For some cloud environments, where port-443 (and 80 perhaps) is intended to
be open,  I can see a mediated ACME process with http-01 challenge, given
that the cloud provider knows a URL at which the VM will be accessible.

I can also see a scenario where a cloud provider could inject an IDevID
into the VM, an operate an RFC8995(BRSKI) MASA, but AFAIK, nobody is doing that.
{The VM *owner* would run the Registrar}

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide