Creation of azure.keyvault.Certiticate fails with

[alexeyzimarev]

Running the certification creation code from the example:
https://pulumi.io/reference/pkg/nodejs/@pulumi/azure/keyvault/#example-usage-generating-a-new-certificate

It consistently fails:

ERROR: 2019/05/11 21:22:34 grpc: server failed to encode response:  rpc error: code = Internal desc = grpc: error while marshaling: proto: field "google.protobuf.Value.Kind" contains invalid UTF-8

[lukehoban]

I was not able to reproduce this error myself - but I believe the example in question here requires some customization to fit with a particular usage environment. If there is a specific repro available that triggers this specific error - I'd love to see it.

[mikhailshilkov]

I'm able to reproduce this same error by copy-pasting that snippet 1-to-1.

[stack72]

I can confirm that I get the same error :

    ERROR: 2019/06/04 18:30:38 grpc: server failed to encode response:  rpc error: code = Internal desc = grpc: error while marshaling: proto: field "google.protobuf.Value.Kind" contains invalid UTF-8

[w0rldart]

Same here

  azure:keyvault:Certificate (test):
    error: Plan apply failed: grpc: error while marshaling: proto: field "google.protobuf.Value.Kind" contains invalid UTF-8

Setup

// Currently, only service principal ID is available in the context.  If we are provided the
// principle in the config, then just use it.  Otherwise, if logged in with a user, find their ID
// via Azure CLI. see https://github.com/terraform-providers/terraform-provider-azurerm/issues/3234
const currentPrincipal = clientConfig.servicePrincipalObjectId !== ""
? clientConfig.servicePrincipalObjectId
: <string>JSON.parse(execSync("az ad signed-in-user show --query objectId").toString());

const keyVault = new azure.keyvault.KeyVault('proxy-ssl', {
  accessPolicies: [{
    certificatePermissions: [
      "create",
      "delete",
      "deleteissuers",
      "get",
      "getissuers",
      "import",
      "list",
      "listissuers",
      "managecontacts",
      "manageissuers",
      "setissuers",
      "update",
    ],
    objectId: currentPrincipal,
    tenantId: clientConfig.tenantId,
  }],
  location: resourceGroup.location,
  resourceGroupName: resourceGroup.name,
  sku: {
    name: 'standard'
  },
  tenantId: clientConfig.tenantId
})

const testCertificate = new azure.keyvault.Certificate("test", {
  certificatePolicy: {
    issuerParameters: {
      name: "Self",
    },
    keyProperties: {
      exportable: true,
      keySize: 2048,
      keyType: "RSA",
      reuseKey: true,
    },
    lifetimeActions: [{
      action: {
        actionType: "AutoRenew",
      },
      trigger: {
        daysBeforeExpiry: 30,
      },
    }],
    secretProperties: {
      contentType: "application/x-pkcs12",
    },
    x509CertificateProperties: {
      // Server Authentication = 1.3.6.1.5.5.7.3.1
      // Client Authentication = 1.3.6.1.5.5.7.3.2
      extendedKeyUsages: ["1.3.6.1.5.5.7.3.1"],
      keyUsages: [
        "cRLSign",
        "dataEncipherment",
        "digitalSignature",
        "keyAgreement",
        "keyCertSign",
        "keyEncipherment",
      ],
      subject: `CN=*.${domainName}`,
      subjectAlternativeNames: {
        dnsNames: [
          // "internal.contoso.com",
          // "domain.hello.world",
        ],
      },
      validityInMonths: 12,
    },
  },
  keyVaultId: keyVault.id,
  name: "generated-cert",
})

[stack72]

So, after extensive investigation, I have found that the upstream provider runs the following:

d.Set("certificate_data", string(*contents))

It then stores it as this in the TF state:

"certificate_data": "0\ufffd\u0003_0\ufffd\u0002G\ufffd\u0003\u0002\u0001\u0002\u0002\u0010\u001b\ufffd-\ufffd\u0005\ufffdMГ'\u001cx\ufffd\u0000\ufffd}\ufffd0\r\u0006\t*\ufffdH\ufffd\ufffd\r\u0001\u0001\u000b\u0005\u00000\u00161\u00140\u0012\u0006\u0003U\u0004\u0003\u0013\u000bhello-world0\u001e\u0017\r190916133550Z\u0017\r200916134550Z0\u00161\u00140\u0012\u0006\u0003U\u0004\u0003\u0013\u000bhello-...

This is pointless. We should be base64 encoding the []byte rather than just calling string on it. Therefore, a PR has been submitted upstream that will return just the base64 encrypted string which will solve this issue

hashicorp/terraform-provider-azurerm#4335

[stack72]

This has been merged upstream now - we just need to wait on the release of the provider and this is good - going to close this issue out - we have the fix in place