Can I send the new cert's thumbprint to the application specified in a Run deployment task?

I’m writing a small console app to perform various highly customized tasks using the new certificate. I’d like to instruct it to receive the cert’s thumbprint so that it can reliably retrieve it from the local store.

Is it possible to run my app in a Run deployment task, sending the thumbprint as a command line argument?

Yes, the easiest way is to add a Powershell deployment task then use that to call a script which then calls your console app with the arguments it requires.

So for instance if your tool was called myapp.exe, stored under C:\tools and the first argument is the thumbprint string then:

param($result)  

C:\tools\myapp.exe $result.ManagedItem.CertificateThumbprintHash

Perfect, thank you very much.

FYI I’m presently on the Community License, but I plan to upgrade soon to help support your good work here. Good job, keep it up!

1 Like

Oh, one other thing…

Is that $result object documented somewhere, so we can see (and get to) its entire API?

I just found the docs for the ManagedItem instance, here. Looks good.

What about the $result object itself? Are its properties/methods documented in similar fashion?

Yes that’s here: certify/CertificateRequestResult.cs at development · webprofusion/certify · GitHub

You’ve covered all the bases, haven’t you? :slightly_smiling_face:

I notice that you’re using the old Azure SDK (understandable).

Are you concerned about them someday pulling the rug out from under us with that?

In V6.0 (recently released and starting to be drip fed to updates) we are using the latest Azure API stuff, except for app services deployment (so we’re using the new SDK for DNS and Key vault).

Their latest SDK is a little bit green here and there and can be tricky to migrate to, it also resulted in a few special cases where various DLLs (Azure Resource, Identity etc) were at conflicting versions so it needs to be carefully managed.

However in regards to keeping current, you should definitely plan to keep the app up to date. We don’t officially support old versions of our app so if there’s a bug the first task is always to update.

Long term the current app + service will move to .net 8+ with a bundled runtime (e.g. the installer will be bigger but you won’t have to separately manage the installed runtime). We’ve had them running under .net core et al for years but our current distribution is still for .net 4.6.2+.

We will also be introducing a version that has a web interface for customers who are mainly using it as a centralised certificate management system. That version will also support being hosted under Linux.

In V6.0 … we are using the latest Azure API stuff

Interesting! Good move, I think.

Their latest SDK … can be tricky to migrate to

Tell me about it! FWIW here’s my latest adventure with that.

1 Like

you should definitely plan to keep the app up to date

Righto. Will keep an eye on that. I’m on v5.*, so I imagine the update will be coming down the pike one of these next times.

That version will also support being hosted under Linux

Sounds like Kestrel. I tend to favor that architecture over IIS—for distributed apps, that is. In fact I’m working on one of those as we speak (Blazor Server deployed to a given machine on the office LAN).

I’m inserting Certify the Web as a central fixture in the thing.

Great stuff!

1 Like