Authentication

How ArpeNetezza authenticates to Netezza, and how it protects the connection. Every option named here is listed in the Connection option reference.

Username and password

The only supported login. Supply User ID and Password (or adbc.arpenz.username / adbc.arpenz.password):

Server=nzhost,5480;Database=SYSTEM;User ID=admin;Password=<pw>

The server chooses how the password travels, during Netezza's HSV2 handshake:

Server request	What the driver sends
Cleartext password	the password as-is
MD5	base64(MD5(salt ‖ password))
SHA-256	base64(SHA-256(salt ‖ password))

A digest keeps the password itself off the wire, but none of these methods encrypts SQL text or result rows, and with cleartext the password itself is readable. Use TLS for that.

To make sure a password is never sent over an unencrypted link, set adbc.arpenz.require_password_encryption=true (connection-string keyword RequirePasswordEncryption). The driver then refuses to answer any password request unless TLS is active:

refusing to send the password: the connection is not encrypted and require_password_encryption is on (use sslmode=require or stronger)

A wrong username or password is reported with the server's own message. After too many failures, Netezza locks the account and says so ("Access denied due to too many unsuccessful login attempts").

TLS

Netezza negotiates TLS inside its HSV2 handshake, before the login. The driver asks for a security level derived from sslmode, and the server answers whether it will encrypt:

sslmode	Asks the server for	If the server declines TLS	Verifies the server
disable	no TLS	— (fails if the server only accepts TLS)	—
prefer (default)	TLS if available	continues in clear	no
require	TLS only	connect fails	no
verify-ca	TLS only	connect fails	certificate chain
verify-full	TLS only	connect fails	chain and host name

• Under prefer, a server that declines TLS gets a plaintext session. Once the server has agreed to TLS, a failed handshake is an error; there is no retry in clear.
• verify-full also matches the host name you connect to (see Host name check and SNI).

netezza://admin:<pw>@nzhost:5480/SYSTEM?sslmode=verify-full&sslrootcert=/etc/nz/ca.pem

Protocol versions

sslmode	Default minimum
prefer	TLS 1.0
require, verify-ca, verify-full	TLS 1.2

TLS 1.3 is used when the server offers it. adbc.arpenz.tls_min_version (1.0, 1.1, 1.2, 1.3; since v0.3.2) overrides the minimum in every mode. Below 1.2 the driver also lowers OpenSSL's security level so that the old versions can be negotiated.

NPS 7

Netezza 7.x servers only offer TLS 1.0 / 1.1, so with require or stricter the connection fails unless tls_min_version is lowered:

Python

db_kwargs = {
    "adbc.arpenz.server":          "nz7host",
    "adbc.arpenz.database":        "SYSTEM",
    "adbc.arpenz.username":        "admin",
    "adbc.arpenz.password":        "<pw>",
    "adbc.arpenz.sslmode":         "require",
    "adbc.arpenz.tls_min_version": "1.0",
}

Not yet validated

An encrypted connection to NPS 7 has not been validated against a live server: TLS 1.0 / 1.1 support is tested against a simulated server only. NPS 7.2.1.7 is validated unencrypted (sslmode=disable). If an NPS 7 server cannot complete the TLS handshake even with tls_min_version=1.0, use sslmode=disable on a trusted network. SSL 3.0 is not supported: the OpenSSL 3 built into the driver does not include it.

Independent of the host's TLS stack

Because the driver brings its own OpenSSL, the TLS versions it can use do not depend on the host. A server that only accepts TLS 1.3 works even where the host's own TLS stack has no TLS 1.3: for example Windows Server 2019 and older (Schannel), or a Linux host whose system OpenSSL is 1.0.x. The limit on Linux is the C library: the released binary needs glibc 2.28 or later (RHEL 8, Debian 10, Ubuntu 20.04 or newer), so RHEL 7 is not supported.

Where trusted certificates come from

ArpeNetezza carries its own copy of OpenSSL 3, linked into the library (the Linux release is built with OpenSSL 3.6.4). It never uses the operating system's TLS stack or certificate store. The client OS does change where trusted certificates are found. For verify-ca / verify-full, the CAs come from, in this order:

1. ssl_root_cert (a PEM file holding the issuing CA, and any intermediate);
2. OpenSSL's default locations: the SSL_CERT_FILE (PEM bundle) / SSL_CERT_DIR (hashed directory) environment variables, else /etc/ssl/cert.pem and /etc/ssl/certs/ on Linux.

Client OS	Without ssl_root_cert
Debian, Ubuntu	Works for publicly signed certificates: /etc/ssl/certs holds the system CAs.
RHEL, Rocky, AlmaLinux 8 and newer	Fails with "unable to get local issuer certificate": the CA bundle lives under /etc/pki. Set ssl_root_cert, or SSL_CERT_FILE=/etc/pki/tls/certs/ca-bundle.crt.
Windows	Fails: the Windows certificate store is not read. Set ssl_root_cert.

On IBM Cloud, set ssl_root_cert on every OS (next section).

IBM Cloud NPS: verify-full needs the intermediate certificate

IBM Cloud NPS presents a publicly signed certificate (DigiCert, for *.<region>.data-warehouse.cloud.ibm.com) but does not send the intermediate certificate, so verify-ca / verify-full fail with unable to get local issuer certificate even when the client's CA store holds the DigiCert root. Give the driver a CA file holding the intermediate and the root:

curl -s -o ibm_nps_ca.pem \
  https://cacerts.digicert.com/DigiCertGlobalG2TLSRSASHA2562020CA1-1.crt.pem
cat /etc/ssl/certs/DigiCert_Global_Root_G2.pem >> ibm_nps_ca.pem   # Debian/Ubuntu path

Python

db_kwargs = {
    "adbc.arpenz.server":        "nz-<instance-guid>.<region>.data-warehouse.cloud.ibm.com",
    "adbc.arpenz.database":      "SYSTEM",
    "adbc.arpenz.username":      "admin",
    "adbc.arpenz.password":      "<pw>",
    "adbc.arpenz.sslmode":       "verify-full",
    "adbc.arpenz.ssl_root_cert": "/path/to/ibm_nps_ca.pem",
}

Connect by the DNS name: verify-full by IP address fails (IP address mismatch), as it should. If your region's certificate has a different issuer, fetch that intermediate instead.

Host name check and SNI

With verify-full, the host name you connect to must match the certificate's DNS SANs (or its CN when it has none); an IP address is matched against its IP SANs. A wildcard must be the whole first label (*.example.com). SNI is always sent, in every mode.

Client certificates

Not supported: the driver presents no client certificate, so servers that require mutual TLS cannot be reached.

OpenSSL configuration

Like any OpenSSL 3 program, the driver reads an OpenSSL configuration file at the first TLS connection: the file named by OPENSSL_CONF, else /etc/ssl/openssl.cnf on Linux. Settings there, such as cipher lists, apply. The driver's minimum TLS version always wins. RHEL's system crypto-policies live under /etc/pki/tls/openssl.cnf, so they apply only if that file is the one loaded (for example with OPENSSL_CONF=/etc/pki/tls/openssl.cnf).

TLS errors are listed under Troubleshooting → TLS.

Not supported

• Kerberos and Windows integrated authentication (SSPI). The integrated-auth options (adbc.arpenz.trusted, adbc.arpenz.auth_type=integrated, Integrated Security=SSPI, Authenticator=krb5, the krb5.* options) are accepted, but every connection then fails before any network I/O with:

  integrated/trusted authentication (Kerberos, SSPI) is not supported for Netezza yet; connect with a username and password

  Combining integrated auth with a password is rejected earlier, at AdbcConnectionInit. A server that itself asks for Kerberos is refused with "authentication type N (Kerberos/crypt) is not yet supported".

• SCRAM and channel binding. Netezza never uses SCRAM, so channel_binding=require is refused at connect; prefer and disable have no effect.

• GSS transport encryption. Netezza has none; gssencmode=require is refused at connect, and prefer has no effect. Use sslmode to encrypt.

• Token authentication (OAuth2, Entra ID, IAM): Netezza has no such login.

• Client certificates: see above.