Link to home
Start Free TrialLog in
Avatar of Shaun Gorman
Shaun GormanFlag for Australia

asked on

How to convert Azure pfx key to pkcs#1

The company I work for has it's certificates in Azure. So when you download them they are in pfx format. I get that they are a bundle and that you can use openssl to extract different version keys. The product tableau requires the certificate as a crt file and key. I have successfully extracted that using Openssl. However it also requires the certificate as a pkcs#1 file and key. I can find lots of articles and commands for converting pkcs#8 to pkcs#1 such as but not for converting pfx to pkcs#1. I can imagine it is a two-stage process so I have been looking for pfx to pkcs#8 but haven't had any luck there either. Can anyone help with how to convert pfx to pkcs#1. Thanks!

Avatar of gr8gonzo
Flag of United States of America image

You said:

The product tableau requires the certificate as a crt file and key. I have successfully extracted that using Openssl.

What commands did you use/ what format did you end up with?

You can definitely do this with openssl in a few steps (I've had to do this exact thing before and I have the commands written in my notes on my desktop) but I'm trying to understand where you -currently- are in the process. Did you export it with openssl but in a different format like pkcs#8 or x.509?

Avatar of Shaun Gorman


Hi gr8gonzo, I installed openssl on my laptop and ran this command: openssl pkcs12 -in yourcurrentfile.pfx -clcerts -nokeys -out yournewcertificate.crt to get a crt file. Then I ran this command :  openssl pkcs12 -in yourcurrentfile.pfx -nocerts -out yournewcertificateencrypted.key to get the key. That gave me a certificate file and key that allowed Https to work for Tableau. This next bit has to have "A PEM-encoded x509 certificate file with a .crt extension" and "PKCS#1 RSA" key. I am required to create a Tableau site. This is the document Tableau have given me to work on: Thanks heaps for taking an interest! Shaun

I'm pretty sure that's what you've already generated, with one exception. 

Your "yournewcertificate.crt" file -is- a PEM-encoded x509 certificate, if you're able to use it for HTTPS. 

And when you export a private key from a PFX like that, you're going to end up with a PKCS#1 RSA key, albeit encrypted. If Tableau wants an unencrypted key, just remove the passphrase with:

openssl rsa -in yournewcertificateencrypted.key -out yournewcertificate.key 

Should a PKCS#1 RSA Key look like this inside? :                                             Bag Attributes
    Microsoft Local Key set: <No Values>
    localKeyID: 01 00 00 00
    friendlyName: {E2F701D5-DF3F-4FEF-8956-577D93E0BF7A}
    Microsoft CSP Name: Microsoft Enhanced RSA and AES Cryptographic Provider
Key Attributes
    X509v3 Key Usage: 10
MIIFL  ...............................................................................................NeoYSENdMUPp4PsUY
Try using the OpenSSL which is already installed with the Tableau server.

Yes that is an RSA private key but it's encrypted with a passphrase. As I mentioned, if you remove the passphrase using the command I provided, you'll see that the format looks more like what you probably expect. 

@Senior Systems Engineer - The openssl version shouldn't matter in this particular case. This is simple format conversion.

WHOA - hold up! I just saw the link and saw you're setting up SAML. Don't continue - bear with me while I write up a new comment.

Okay so when you're setting up SAML, there should be TWO separate keypairs:

One keypair on the IdP (which I'm 99.9% certain is Azure in this case).

One keypair on the SP (tableau).

They should NOT be the same keypair. After some coffee and rereading your question, I'm pretty sure you're trying to export the IdP keypair and use it in Tableau (the SP). Don't do this.

Each keypair has two district functions - encryption and digital signing.


The public key is what encrypts data, while the private key decrypts data.

So if you want someone to encrypt data that only you can decrypt, you generate a keypair and give them the public key / certificate. They use the public key to encrypt data and send it to you, and then you use your private key to decrypt the data.

If you want secure two-way communication, you simply repeat the same process on both sides. The other person generates their own keypair and sends you their public key. You use it to encrypt data and send the data to them, and they use their private key to decrypt it.

Digital signing:

The private key can generate a digital signature for some data. The digital signature is a hash that "represents" what the data looked like at the time of the signature. The public key can validate that the digital signature matches the data, so if someone changes the data in any way, the signature won't be right and the data can be considered untrustworthy.

In SAML, the IdP (Azure) generates a keypair. You give the public key to the SP (Tableau).

Then you generate another keypair for Tableau and configure the SP connection in Azure to use the public key from Tableau.

When it's time to authenticate, the IdP generates a SAML assertion, which is just a chunk of XML. The assertion contains a "subject" which is basically the unique identifier of the person who is logging in . It is often either an email address or a user name or some ID.  It also has other restrictions like timestamps and so on.

Then the IdP uses the SP's public key to encrypt the assertion, and then uses the IdP to digitally sign the assertion. The finished (encrypted and signed) assertion is encoded for transmission and then the user's browser takes this result and transmits it to the SP.

The SP takes the assertion and uses the IdP public key to validate the digital signature to make sure the assertion hasn't been tampered with. Then the SP uses its private key to decrypt the assertion and consume it to log the user in.

So that's the flow and that's why you need two separate keypairs - two systems should never have the same private key. 

So Azure generates its own self signed keypair for your SP connection. You just need to generate a separate keypair (use openssl) for Tableau and make sure it's public key is set up in Azure.

Does all that make sense?

Avatar of dfke


can't you just:

openssl pkcs12 -in your.pfx -nocerts -nodes -out privatekey_pkcs8.pem
openssl rsa -in privatekey_pkcs8.pem -outform PEM -out privatekey_pkcs1.pem

Open in new window


@dfke - no. That command doesn't produce anything different than the steps that were already provided but the bigger issue here is that this is SAML, so the OP shouldn't be trying to bring the Azure keypair into Tableau. Each system should have it's own keypair and exchange public keys. So the OP needs to just generate a new RSA keypair for Tableau.

Thanks for your thoughts so far dfke and gr8gonzo. The Tableau engineer showed me an error where the key is not pkcs#1 in the Tableau logs. He also opened the certificate and was able to show me that the header has "-----BEGIN PRIVATE KEY-----" and with a pkcs#1 key it will have "-----BEGIN RSA PRIVATE KEY-----". And Tableau requires the key file to be .key not .pem dfke. It appears your command outputs .pem? And right now SAML is working for Tableau Server with the existing .pem and .key file. But it isn't working for Tableau sites. The Tableau engineer says that is because the .key file is not PKCS#1.

> And right now SAML is working for Tableau Server with the existing .pem and .key file

I'm not sure what you mean by this. Again, it is very important that you do not ever share a private key between more than one site/entity, especially not share the IdP private key with the SP (or vice-versa). That is a significant security problem.

Again, if you're trying to provide a keypair for an SP, just generate a new one.

And while the commands I provided should produce a pkcs#1 RSA key, please, please, please do not continue trying to convert the Azure pfx. 

I do SAML integrations all the time. If you tell the tableau engineer that you are trying to reuse the private key from your IdP, they should tell you the same thing - not to do it (as long as they are experienced enough to know better).

I can guide you through generating a new keypair if you want.

Hi gr8gonzo, the Tableau server configuration page allows for single sign on. Currently that works with single sign on. The Tableau site that the server provides for customers doesn't work.  Tableau has a restriction that the site only allows single sign on using a PKCS#1 RSA Key. Not for the Tableau server configuration page.

Hi Shaun,

Yes, an individual site is considered a separate SP and needs its own keypair. When you generate one with openssl, you can have it generate a PKCS#1 RSA key.

Per the Tableau documentation:

Server-wide SAML authentication and site-specific SAML authentication.

In a multi-site environment, all users authenticate through a SAML IdP configured at the site level, and you specify a server-wide default SAML IdP for users that belong to multiple sites.

If you want to use site-specific SAML, you must configure server-wide SAML before you configure individual sites. Server-side SAML does not need to be enabled for site-specific SAML to function, but it must be configured.

Avatar of Shaun Gorman
Shaun Gorman
Flag of Australia image

Link to home
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial

Sigh. I don't know if you simply did not understand what I was saying, but you seem determined to go down the wrong path.

You are basically asking for instructions on how to create a security problem and not responding to the advice that says. "don't do that - do this instead"

Good luck with that.