'key' field on host_key_cert model (REST API)

Hey all,

Really excited by the REST API; I've been keen to implement Let's Encrypt for a while now and this has really opened the door to it.

I've been making some good progress, but I'm just looking to add my new certificate to the UTM, and having trouble posting the key.

I'm getting the error 'The X509 certificate with private key object requires text data for the private key attribute.'

Does anyone know what format the key needs to be in for the API to accept it? I've been trying to post it as the normal '-----BEGIN PRIVATE KEY-----' etc block (as seen when I do a GET on that same endpoint) but not having much luck.

 

Secondly, I note that the 'meta' reference needs to be populated; am I correct in my current process of first posting a new meta record, then using the corresponding ref when I go to add the actual certificate (with host_key_cert)?

 

Thanks!

  • Hmm I may have solved this one.

    For anyone wondering, it looks to be related to the way I was reading in my key file, I'm guessing possibly related to a BOM on the text file that wasn't immediately obvious. Cheers :)

  • In reply to Brad Reeve:

    Would be nice if you share your knowledge with us.

    My current way to use a lets'encrypt certificate for my UTM is to create one on my Synology NAS, then export it with private key and installing it on the UTM. It's working for me, but requires more than a few mouse clicks... :-D

  • In reply to kerobra:

    I can certainly outline my approach, I'd need to get approval to share code but if I end up with anything useful I'll investigate that :)

    Most of our infrastructure is Windows based so I'm going for a Powershell approach. Here's a rough outline:

    I've done a little initial setup, where I've added additional site path routing rules for each site publishing rule on our UTM for "/.well-known/acme-challenge/". These are mapped back to a central 'validation server' that is responsible for dealing with the Let's Encrypt ACME challenges over HTTP. This means I can just deal with the challenges in one location, and the UTM will handle the various domains for me.

    In order to issue the actual certs, I make a call to /objects/reverse_proxy/frontend/, which gets a list of the reverse proxy/site publishing rules. Something like:

    $headers = @{
        Accept = "application/json"
        Authorization = "Basic dG9rZW46YXBpa2V5"
    }

    $rules = Invoke-RestMethod -Method Get -Uri "$apiRoot/objects/reverse_proxy/frontend/" -Headers $headers

    The returned data has a 'domain' field containing a list of the DNS names used by that rule. I then use ACMESharp to setup the LE identifiers for each DNS name, manually handling the challenge via HTTP, by creating the response file and copying it to my previously mentioned central location. When it comes time to generate the certificate, it's important too add *all* the DNS names to the subject alternate names, that way your single certificate will cover the entire UTM rule.

    New-ACMECertificate $sanList[0] -Generate -AlternativeIdentifierRefs $sanList -Alias $certAlias -VaultProfile $config.Vault

    (Where sanList is an array of DNS names).

    To get the cert back on to the UTM, you first need to create a /objects/ca/meta_x509/ record, followed by a /objects/ca/host_key_cert/ record, which I'm just finish off now.

    Next step is to configure the UTM publishing rule to us the new certificate, and I'm hopeful it will be all automated.

    Anyway, once I'm done I'll see if we are happy to share what we've got. Happy to answer any questions though.

    Cheers!

  • In reply to Brad Reeve:

    Thanks for sharing, Brad, and welcome to the UTM Community!  What a great start!  Thanks also to Kevin for asking you to share.

    I have prioritized your thread at the top of the forum for the foreseeable future.

    Cheers - Bob

  • In reply to BAlfson:

    Thanks for the kind words Bob!

    I've made some good progress and have successfully tested our initial concept on a couple of our minor sites. This encompasses the initial validation challenge/certificate issuance from Let's Encrypt through to deploying the certificate to the appropriate site publishing rule. I must say the REST API has been really great, I'm sure there are plenty of new opportunities that will arise with it.

    I'll see what I can do about packaging up what we have; it's a bit rough around the edges and there are some changes I'd want to make first, but if nothing else it's a proof of concept that others can run with.

    Cheers,
    Brad