Connect Excel to Snowflake with a private key on Windows

To pull Snowflake data into Excel with key-pair authentication, you need three things: a private key on your computer, its matching public key registered against your Snowflake user, and an ODBC data source that points to the private key.

The private key stays local. Snowflake gets the public key. Excel connects through the Snowflake ODBC driver.

I previously wrote a Snowflake key-pair setup guide for Tableau on LinkedIn. This guide covers the Excel connection and uses AES-256-CBC for the encrypted key rather than the older encryption example in that post.

This walkthrough is for Excel desktop on Windows using Power Query and ODBC. It covers an interactive workbook refresh, not an unattended refresh service or Excel for the web. Ask your Snowflake administrator whether key-pair authentication is appropriate for your account and identity before starting. Keep your organization's authentication and device-security policies in place.

The final test is simple: save the workbook, close Excel completely, reopen it, and refresh successfully. A connection that works only during the setup session is not finished.

Using a Mac? Follow the separate Excel for Mac and Snowflake private-key guide.

1. Check the existing connection first

If the workbook already connects to Snowflake, make a backup before changing anything. Close Excel while you update its connection settings.

Record these values with your administrator:

• Exact Snowflake login name. Do not assume it is your email address.
• Snowflake server hostname, without https:// or a browser-page path.
• Warehouse, role, database, and schema.
• Existing ODBC data source name, or DSN.
• Excel architecture and installed ODBC driver version.

In Excel, File → Account → About Excel shows whether you have a 32-bit or 64-bit installation. Use the matching ODBC driver and ODBC Data Source Administrator. A 64-bit Windows installation does not mean that Excel is necessarily 64-bit.

If a working Snowflake driver and DSN are already installed, inspect them before installing another driver or creating another DSN. A driver upgrade can affect other workbooks. Snowflake's Windows ODBC installation guide covers architecture and installation requirements; use the documentation for your installed major version.

Also inspect the workbook's query source. A query using Snowflake.Databases(...) uses the native connector. Changing an ODBC DSN will not change that query. We will handle that distinction after testing a blank workbook.

2. Find OpenSSL and choose a local key folder

Open PowerShell and check:

$openssl = (Get-Command openssl -ErrorAction Stop).Source
& $openssl version

If it is installed but not on your PATH, use its actual executable path. For example:

$openssl = "C:\Program Files\OpenSSL-Win64\bin\openssl.exe"
& $openssl version

That path is an example, not a guarantee. If neither command works, OpenSSL may need to be installed. With your organization's approval, one Windows package option is:

winget install --id ShiningLight.OpenSSL.Light --exact --source winget

Wait for the installer to finish, including any administrator approval window. “Preparing to install” is not a completion message. Reopen PowerShell after installation, assign $openssl to the actual executable path, and run & $openssl version again. The commands below assume that check succeeds.

Choose a local folder that your Windows account can read and that is not a shared or automatically synchronized folder. Restrict access according to your organization's policy. Encryption does not replace file permissions.

$keyDir = Join-Path $env:USERPROFILE "SnowflakeKeys"
New-Item -ItemType Directory -Force $keyDir | Out-Null
$privateKey = Join-Path $keyDir "excel_snowflake.p8"
$publicKey = Join-Path $keyDir "excel_snowflake.pub"

if ((Test-Path $privateKey) -or (Test-Path $publicKey)) {
    throw "A key file already exists. Review it before generating another key."
}

Do not overwrite a key that another connection may still use. Review the folder's access permissions before continuing.

3. Generate the encrypted private key and public key

Run this as one line in PowerShell:

& $openssl genrsa 2048 | & $openssl pkcs8 -topk8 -v2 aes-256-cbc -inform PEM -out $privateKey

OpenSSL prompts for a passphrase. Use a strong one and keep it in your approved password manager. Do not put it directly in the command, a workbook, a chat message, or a script.

Then generate the public key:

& $openssl rsa -in $privateKey -pubout -out $publicKey

Enter the same passphrase when prompted. Password input may show no characters as you type; this is normal. Stop if either command reports an error.

You should now have:

• excel_snowflake.p8: the encrypted private key. Keep this private.
• excel_snowflake.pub: the public key. This is the file your Snowflake administrator needs.

The private key's passphrase is separate from your Snowflake password. The ODBC driver uses it locally to unlock the key. See Snowflake's key-pair authentication guide for supported formats and key-management options.

4. Register the public key without replacing a working key

Have an authorized Snowflake administrator inspect the target user's existing keys first:

DESCRIBE USER EXAMPLE_USER;

Replace EXAMPLE_USER with the exact user identifier. Quoted, case-sensitive identifiers need their original quoting.

For an unused RSA_PUBLIC_KEY slot, the administrator can register the public key body:

ALTER USER EXAMPLE_USER
  SET RSA_PUBLIC_KEY = '<PUBLIC_KEY_BODY>';

Copy only the public key's base64 body, without its BEGIN PUBLIC KEY and END PUBLIC KEY lines or line breaks. Never paste the private key into SQL.

If the first slot is already used, do not replace it casually. The administrator can use an approved rotation process or an unused RSA_PUBLIC_KEY_2 slot. If both are occupied, stop and establish what uses them. Snowflake also supports named key pairs; follow the account's established key-management approach rather than mixing procedures without review.

Compare the fingerprints

For the RSA property approach above, inspect RSA_PUBLIC_KEY_FP in DESCRIBE USER. For the second slot, inspect RSA_PUBLIC_KEY_2_FP.

Compute the public key's fingerprint locally. These commands use intermediate files because piping binary data through older Windows PowerShell versions can change the bytes:

$publicDer = Join-Path $keyDir "excel_snowflake_public.der"
$publicHash = Join-Path $keyDir "excel_snowflake_public.sha256"

& $openssl rsa -pubin -in $publicKey -outform DER -out $publicDer
& $openssl dgst -sha256 -binary -out $publicHash $publicDer
& $openssl enc -base64 -in $publicHash

Compare the base64 output with the Snowflake fingerprint after its SHA256: prefix. They should match. These intermediate files contain public-key material, not the private key.

Key registration establishes authentication. It does not grant data access. Separately confirm the intended role is granted to the user and has the required warehouse, database, schema, and object privileges. Use a read-only reporting role, not an administrative role, for ordinary Excel reporting.

5. Configure the Snowflake ODBC data source

Open the matching Windows ODBC Data Source Administrator. Edit the existing Snowflake DSN, or create a User DSN if this is a new personal connection.

Keep the server, user, warehouse, role, database, and schema consistent with the values you checked earlier. Set the key-pair parameters:

Parameter	Value
AUTHENTICATOR	SNOWFLAKE_JWT
PRIV_KEY_FILE	Full local path to excel_snowflake.p8
PRIV_KEY_FILE_PWD	The private key's passphrase

Use an actual absolute file path, not the PowerShell variable name $privateKey. The passphrase belongs in the driver's key-passphrase field, not the ordinary Snowflake password field.

Check how your installed driver stores and retrieves the passphrase before saving it. A DSN or Windows registry entry is not a password vault. Storing the key and a readable passphrase on the same computer weakens the protection from encryption. If your organization does not permit this storage, have IT configure an approved way to supply the passphrase or choose an approved interactive authentication method. Do not remove encryption simply to make refresh easier.

Windows dialog has a password box but no private-key fields

A password box can remain visible even after you enter SNOWFLAKE_JWT in Authenticator. Leave the ordinary Password field blank. The key-file path and key passphrase are separate settings.

Save the Authenticator change with OK, then close ODBC Data Sources completely before editing its registry settings. For the User DSN workflow below, use Registry Editor, not PowerShell:

1. Press Windows + R, enter regedit, and press Enter.
2. Navigate to HKEY_CURRENT_USER\SOFTWARE\ODBC\ODBC.INI\<DSN_NAME>, replacing <DSN_NAME> with the existing connection's name. For a User DSN named snowflake, the last folder is snowflake.
3. Confirm the existing server, user, and database match the connection you just inspected. If the branch is absent, stop and check DSN scope, architecture, and Windows account. Do not create a guessed branch. System DSNs use a different location; these instructions target a User DSN.
4. In the right-hand pane, right-click empty space and choose New → String Value. Name it exactly PRIV_KEY_FILE. If it already exists, edit it.
5. Double-click that value. Set its data to the full local .p8 path, for example C:\Users\YourWindowsName\SnowflakeKeys\excel_snowflake.p8, without surrounding quotation marks. Do not paste $env:USERPROFILE or $privateKey into this field.
6. If your organization's approved setup permits a stored passphrase, add a second String Value named PRIV_KEY_FILE_PWD and enter the key passphrase locally. This REG_SZ value is readable text, not an encrypted credential store. Keep it out of screenshots and screen sharing.
7. These must be values in the right-hand pane, not new subfolders under the DSN. Close Registry Editor.
8. Reopen ODBC Data Sources → User DSN → your connection → Configure. Confirm Authenticator still reads SNOWFLAKE_JWT; re-enter it if the earlier edit was not saved. Click Test, then OK to save the configuration after a successful test.

Excel selects the DSN by name. Windows supplies that DSN's settings to the driver, and PRIV_KEY_FILE tells the driver where to read the key. A workbook does not discover the key automatically or receive it from Snowflake.

“Required setting PRIV_KEY_FILE is not present”

This error means the driver did not receive the file-path setting. It does not yet establish a bad passphrase or a mismatched public key.

Check the exact value name, REG_SZ type, nonempty absolute path, and that you edited the same User DSN under the Windows account running Excel. If the setting is visible but Test still reports it missing, cancel any configuration dialog left open during the registry edit, close ODBC Data Sources completely, and reopen it before testing again. An already-open dialog may still have older settings. Recheck Authenticator after reopening: canceling an unsaved dialog can discard the SNOWFLAKE_JWT edit. Re-enter it if needed, test, and save with OK. In a Windows setup session, reopening the dialog and restoring this setting was followed by a successful ODBC test and Excel loading data; that observation does not isolate which change resolved the error. If the error persists, verify the driver architecture and actual DSN rather than regenerating keys.

Snowflake documents the exact key-pair parameters in its ODBC connection reference. Keep credentials out of Power Query M code and workbook connection strings.

6. Test a blank Excel workbook

Start with a blank workbook so that connection problems are separate from existing query logic.

1. Select Data → Get Data → From Other Sources → From ODBC.
2. Choose the Snowflake DSN you configured.
3. If Excel asks for an authentication method, select Default or Custom on the left, leave the optional credential connection-string box blank, and click Connect. If Database is selected, Excel is trying database username/password authentication instead of the intended driver-configured flow.
4. Load a small, approved table or view through Navigator, or use a small SQL query under Advanced options.

For a basic connection-context check:

SELECT
  CURRENT_USER() AS CONNECTED_USER,
  CURRENT_ROLE() AS CONNECTED_ROLE,
  CURRENT_WAREHOUSE() AS CONNECTED_WAREHOUSE,
  CURRENT_DATABASE() AS CONNECTED_DATABASE,
  CURRENT_SCHEMA() AS CONNECTED_SCHEMA;

Then query a small amount of the reporting data you actually need. A context query can succeed even when the role cannot read your target table.

Microsoft's Power Query ODBC connector guide explains the DSN and authentication choices. It also notes that attributes appended after a DSN in the connection string are not included; configure the required attributes in the DSN itself.

7. Update the real workbook and test reopening

Open the backup copy of your report and inspect Data → Queries & Connections.

If it already uses the same ODBC DSN, refresh one query first. If it uses the native Snowflake connector, create and validate an ODBC source before replacing its source step. The navigation structure can differ, so preserve and check the downstream transformation steps rather than blindly changing a function name.

A minimal ODBC query uses only the DSN and SQL:

let
    Source = Odbc.Query(
        "dsn=SnowflakeReporting",
        "SELECT CURRENT_USER() AS CONNECTED_USER, CURRENT_ROLE() AS CONNECTED_ROLE"
    )
in
    Source

Replace SnowflakeReporting with your DSN name. Keep keys and passphrases out of this code.

Finish with this sequence:

1. Refresh one query and compare expected rows, columns, types, and totals.
2. Refresh all queries and check dependent formulas, PivotTables, and charts.
3. Save the workbook and close every Excel window.
4. Reopen Excel and the saved workbook.
5. Refresh again using the approved credential flow.

If the workbook is shared, the recipient needs their own authorized identity, local driver, DSN, and credential setup. Sending the workbook should not send your private key. Also review whether the workbook itself contains cached data that should not be shared.

Troubleshooting without changing everything at once

Symptom	Check first
DSN is missing in Excel	Excel/driver architecture, User versus System DSN, and the Windows account running Excel
“Required setting PRIV_KEY_FILE is not present”	Exact registry value name, correct DSN, and fully reopening ODBC Data Sources after edits
Private key cannot be read	Absolute path, file permissions, encrypted PKCS#8 format, and passphrase
JWT authentication fails	Exact login name, account hostname, public-key fingerprint, machine clock, and account authentication policy
Login works but a table is missing	Active role and database/schema/object privileges
Excel still asks for the old password	Authentication selection and cached permissions for this specific connection
Blank workbook works but the report fails	Native connector versus ODBC, source navigation, and downstream query steps
Refresh fails only after reopening	Passphrase persistence, file access, and whether the workbook retained the correct DSN

If Excel only says “We couldn’t authenticate with the credentials provided,” cancel and use the ODBC configuration dialog’s Test button to obtain the more specific driver error. Hide credentials when sharing that error.

If cached credentials are the problem, review Data → Get Data → Data Source Settings and clear permissions only for the affected connection. Avoid clearing every connection in a working reporting environment.

Stop repeated retries when an error persists. Record the exact error, Excel architecture, driver version, and the step that failed, with credentials hidden. The goal is to isolate authentication, authorization, and workbook behavior separately.

For the Snowflake roles and grants behind this connection, see Snowflake initial setup. Once the workbook reliably refreshes after reopening, record who owns the key, the approved rotation process, and where the connection settings are documented. Do not include the secret itself in that handover.