Azure / azure-powershell

Microsoft Azure PowerShell
Other
4.22k stars 3.83k forks source link

Add-AzureCertificate doesn't appear to upload private key part of pfx file via X.509 overload #1443

Closed matt-richardson closed 7 years ago

matt-richardson commented 8 years ago

Add-AzureCertificate has the ability to receive the -certToDeploy as either a string (filename) or an X509Certificate2 object.

When using the overload that takes the X509Certificate2 object, it doesn't appear to upload the private key part of the certificate:

$FileName = "c:\temp\azure-cert.pfx"
$OutputName=$fileName+".b64";
$FileContent = [System.IO.File]::ReadAllBytes($FileName); 
$FileContentEncoded = [System.Convert]::ToBase64String($FileContent) 
$FileContentEncoded|set-content($OutputName); 
...
$base64certificate = [System.IO.File]::ReadAllText("$OutputName")
$certBytes = [System.Convert]::FromBase64String($Base64Certificate)
$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2($certBytes, "PassW0rd", [System.Security.Cryptography.X509Certificates.X509KeyStorageFlags]"UserKeySet")
Add-AzureCertificate -CertToDeploy $cert -ServiceName "my-api" -Password "PassW0rd"

it fails with an error when the certificate is used in a cloud service deployment via New-AzureDeployment:

New-AzureDeployment : BadRequest : Certificate with thumbprint XXXXX associated 
with HTTPS input endpoint XXXX does not contain private key.
At D:\Octopus\Work\20151208145039-65\DeployToAzure.ps1:75 char:5
+     New-AzureDeployment -Slot $OctopusAzureSlot -Package $OctopusAzurePackageUri ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : CloseError: (:) [New-AzureDeployment], ComputeCloudException
    + FullyQualifiedErrorId : Microsoft.WindowsAzure.Commands.ServiceManagement.HostedServices.NewAzureDeploymentCommand
Script 'F:\Octopus\Work\20151208145039-65\DeployToAzure.ps1' returned non-zero exit code: 1

(Before you ask, the reason its writing it to a file first is the certificate is stored in OctopusDeploy as Base64 encoded text).

However, if it gets written to a file, and the file based overload is used, it works:

$FileName = "c:\temp\azure-cert.pfx"
$OutputName=$fileName+".b64";
$FileContent = [System.IO.File]::ReadAllBytes($FileName); 
$FileContentEncoded = [System.Convert]::ToBase64String($FileContent) 
$FileContentEncoded|set-content($OutputName); 
...
$base64certificate = [System.IO.File]::ReadAllText("$OutputName")
$certBytes = [System.Convert]::FromBase64String($Base64Certificate)
#$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2($certBytes, "PassW0rd", [System.Security.Cryptography.X509Certificates.X509KeyStorageFlags]"UserKeySet")
#Add-AzureCertificate -CertToDeploy $cert -ServiceName "my-api" -Password "PassW0rd"
[System.IO.File]::WriteAllBytes("c:\temp\tempfilename.pfx", [System.Convert]::FromBase64String($Base64Certificate))
Add-AzureCertificate -CertToDeploy "c:\temp\tempfilename.pfx" -ServiceName "my-api" -Password "PassW0rd"

Either I'm doing something crazy, or there's a mismatch between the two bits of functionality. Can you take a look?

matt-richardson commented 8 years ago

Looks like its hitting the CryptographicException, and then returning cert.RawData, which doesn't appear to contain the private key...

markcowl commented 8 years ago

@singhkay Can you take a look?

singhkays commented 8 years ago

@hyonholee Can you take a look at the X509Certificate2 code?

cormacpayne commented 7 years ago

@twitchax: "Azure PowerShell continues to maintain RDFE support on a legacy basis: new functionality and bug fixes are addressed sparingly. This issue does not meet the current threshold for consideration."

aggFTW commented 6 years ago

This drove me nuts for a few hours. What is the criteria to determine when a bug needs a fix?

mikeblakeuk commented 5 years ago

@matt-richardson Any news on this? We are hitting the same issue if we don't save the pfx first... (Hi btw!)

matt-richardson commented 5 years ago

Hey @mikeblakeuk! Even though this should've been relatively simple, it was closed as wont fix. Only workaround is to save to file first.