capiLocation used for afterInstallAction location falsely

[dcherry88]

PROBLEM SUMMARY When using playbook for CAPI install, it seems to still be storing the capilocation in a "location" even when the yaml has capiLocation specified instead of Location. The end result is that the afterInstallAction step fails to run because it tries to use this location for the script.

STEPS TO REPRODUCE Use latest version of vCert with CAPI install yaml config. Specify capiLocation but leave Location out of yaml. Run vcert utility with yaml

EXPECTED RESULTS afterInstallAction should not reference the capiLocation when running it's step.

ACTUAL RESULTS vcert attempts to run afterInstallAction from path specified in capiLocation as if it's the location of the command/scripts.

ENVIRONMENT DETAILS Latest version of vCert 5.1.1. Running on a Windows Server 2022 Std system. Repeatable across systems.

[BeardedPrincess]

Thanks for reporting this @dcherry88 .. I will do some investigation into this.

[BeardedPrincess]

@dcherry88,

I am not able to replicate this issue using vCert 5.1.1. My afterInstallAction is working as expected when I have defined capiLocation.

The only reference to location that I see is on a debug log output where the code is saying it is running afterInstallActions for the certificate installed in CAPI. You can inspect that line here: https://github.com/Venafi/vcert/blob/d785595fc65fb3adf316feb74211e8191c8826b5/pkg/playbook/app/installer/capi.go#L166

Although the text string reads "location" (consistent with all the other installers), you can see in the code that it's actually using r.CAPILocation.

My installation looks like this, and is working fine:

certificateTasks:
    - installations:
        - afterInstallAction: $Env:VCERT_MYCERTIFICATE_THUMBPRINT | out-file c:\vcert\log.txt -Append
          capiFriendlyName: Obether
          capiIsNonExportable: true
          capiLocation: LocalMachine\My
          format: CAPI
      name: myCertificate
      renewBefore: 50%
      request:
        csr: local
        subject:
            commonName: '{{ Hostname | ToLower -}}'
        zone: Certificates\vcertplus
      setEnvVars:
        - thumbprint
        - serial
config:
    connection:
        credentials:
            accessToken: REDACTED==
            clientId: vcert-plus
            refreshToken: REDACTED==
            scope: certificate:manage
        platform: tpp
        trustBundle: trustedRoot.cer
        url: https://jhtpp231.lab.REDACTED

[dcherry88]

Attaching a copy of debug output as well as a layout of my yaml as it currently is. debug.log dchertest.capi.yaml.txt

[BeardedPrincess]

Ahh.. I think I see the issue. When the code calls an afterInstallAction for windows, it automatically assumes powershell.exe for the execution environment. So, the command becomes powershell.exe <WHATEVER_YOU_PUT_IN_THE_FIELD>. In my testing, running a script worked with afterInstallAction: c:\vcert\update.ps1.

Powershell.exe doesn't have a -script parameter (at least not on my Windows 11:

PS C:\vcert> powershell.exe -h

PowerShell[.exe] [-PSConsoleFile <file> | -Version <version>]
    [-NoLogo] [-NoExit] [-Sta] [-Mta] [-NoProfile] [-NonInteractive]
    [-InputFormat {Text | XML}] [-OutputFormat {Text | XML}]
    [-WindowStyle <style>] [-EncodedCommand <Base64EncodedCommand>]
    [-ConfigurationName <string>]
    [-File <filePath> <args>] [-ExecutionPolicy <ExecutionPolicy>]
    [-Command { - | <script-block> [-args <arg-array>]
                  | <string> [<CommandParameters>] } ]

PowerShell[.exe] -Help | -? | /?

[dcherry88]

So i actually put that in thinking it was why the location got messed up. The error exists when not using the non-existenent -script option.

New debug with it removed. debug.log

[BeardedPrincess]

It seems that something in that script is failing and erroring out (it's returning a non-success error code). Unfortunately, it doesn't seem to be capturing what that error might be. If you could provide the UpdateIISBinding.ps1, I'd be happy to have a look. If you can't/don't wanna post it here, you can open a Venafi support ticket, and provide it through there.

[dcherry88]

Found the confirmed script issue. My apologies for chasing a syntax error. I guess I would close this with the suggestion of something more verbose in the output. Due to the way this was phrased in the command line, it feels like it was a bit misleading on what the error was. Thanks for the help!