You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
We do not receive the expected secret value when attempting to read after updating from 1.7.0 to 1.13.0.1.
VaultSharp Version 1.13.0.1
Vault Version 1.15.4-1
Does this work with Vault CLI?
Yes
Sample Code Snippet
var authMethod = new TokenAuthMethodInfo(_settings.Certificate.VaultToken);
var vaultClientSettings = new VaultClientSettings(_settings.Certificate.VaultServerUri, authMethod);
var vaultClient = new VaultClient(vaultClientSettings);
var mountPoint = string.IsNullOrWhiteSpace(_settings.Certificate.VaultSecretMountPoint) ?
null : _settings.Certificate.VaultSecretMountPoint;
var secret = await vaultClient.V1.Secrets.KeyValue.V2.ReadSecretAsync(
path: _settings.Certificate.VaultSecretPath,
mountPoint: mountPoint);
if (secret?.Data?.Data?.ContainsKey(_settings.Certificate.VaultSecretDataKey) ?? false)
{
var certData = secret.Data.Data[_settings.Certificate.VaultSecretDataKey] as string;
return new X509Certificate2(Convert.FromBase64String(certData),
_settings.Certificate.VaultSecretFilePassword);
}
else
{
_logger.LogError("No secret found in Hashicorp Vault with key {key}", _settings.Certificate.VaultSecretDataKey);
}
Exception Details/Stack Trace/Error Message
System.ArgumentNullException: Value cannot be null. (Parameter 's')
at System.Convert.FromBase64String(String s)
at Bit.KeyConnector.Services.HashicorpVaultCertificateProviderService.GetCertificateAsync() in /home/runner/work/key-connector/key-connector/src/KeyConnector/Services/HashicorpVaultCertificateProviderService.cs:line 33
Any additional info
When we upgrade from 1.7.0 to 1.13.0.1, the data that is returned in the secret.Data.Data[key] element can no longer be parsed as a valid base64-encoded string. This appears to be because the contents are not being successfully retrieved from the call to ReadSecretAsync. See below.
Running from 1.7.0, the data property of the JSON response when calling ReadSecretAsync is "data":{"data":{"file":"<snip>"}, where <snip> replaces the contents of the encoded string value.
Running from 1.13.0.1, the data property of the JSON response when calling ReadSecretAsync is "data":{"data":{"file":{"ValueKind":3}}.
I have checked the version update notes and do not see any breaking changes that could have caused this change in behavior, and we are not sure what request changes we might need to make to retrieve the key value correctly on the latest version.
The text was updated successfully, but these errors were encountered:
Describe the bug
We do not receive the expected secret value when attempting to read after updating from
1.7.0
to1.13.0.1
.VaultSharp Version
1.13.0.1
Vault Version
1.15.4-1
Does this work with Vault CLI?
Yes
Sample Code Snippet
Exception Details/Stack Trace/Error Message
System.ArgumentNullException: Value cannot be null. (Parameter 's')
at System.Convert.FromBase64String(String s)
at Bit.KeyConnector.Services.HashicorpVaultCertificateProviderService.GetCertificateAsync() in /home/runner/work/key-connector/key-connector/src/KeyConnector/Services/HashicorpVaultCertificateProviderService.cs:line 33
Any additional info
When we upgrade from
1.7.0
to1.13.0.1
, the data that is returned in thesecret.Data.Data[key]
element can no longer be parsed as a valid base64-encoded string. This appears to be because the contents are not being successfully retrieved from the call toReadSecretAsync
. See below.Running from
1.7.0
, thedata
property of the JSON response when callingReadSecretAsync
is"data":{"data":{"file":"<snip>"}
, where<snip>
replaces the contents of the encoded string value.Running from
1.13.0.1
, thedata
property of the JSON response when callingReadSecretAsync
is"data":{"data":{"file":{"ValueKind":3}}
.I have checked the version update notes and do not see any breaking changes that could have caused this change in behavior, and we are not sure what request changes we might need to make to retrieve the key value correctly on the latest version.
The text was updated successfully, but these errors were encountered: