IBM Quantum Platform SSL/TLS Configuration Guide

Understanding SSL/TLS Security for IBM Quantum Cloud Computing

Securing your quantum computing applications requires a comprehensive understanding of how Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protect data transmission between your client applications and the IBM Quantum Platform. Unlike traditional infrastructure management platforms, quantum computing environments present unique security challenges due to their cloud-native architecture, RESTful API-based access patterns, and the emerging threat of quantum computing itself to current cryptographic standards.

This comprehensive guide walks you through implementing, configuring, and maintaining SSL/TLS security for IBM Quantum Platform connections. Whether you're developing quantum applications using Qiskit, connecting via REST APIs, or managing enterprise quantum workflows, understanding these security mechanisms is critical for protecting your quantum algorithms and results from interception and tampering.

For foundational SSL concepts, see our guides on What is SSL, How SSL Works, and What is PKI.

Part 1: Foundational Concepts - SSL/TLS in Quantum Computing Environments

What Is SSL/TLS and Why It Matters for IBM Quantum

Transport Layer Security (TLS) is the cryptographic protocol that ensures encrypted, authenticated communication between your applications and IBM Quantum Platform servers. When you submit a quantum circuit or retrieve computation results, TLS creates a secure tunnel that prevents eavesdropping, man-in-the-middle attacks, and data modification.

SSL, the predecessor to TLS, is now considered obsolete due to multiple critical vulnerabilities. Modern deployments exclusively use TLS versions 1.2 and 1.3, which IBM Quantum Platform requires for all connections. Learn more about the differences in our SSL vs TLS vs HTTPS guide.

Key components of TLS security include:

The Current TLS Architecture of IBM Quantum Platform

IBM Quantum Platform uses a multi-layer security architecture to protect quantum computing workloads:

Understanding Certificate Validation in Quantum Computing Context

When your Qiskit application first connects to quantum.cloud.ibm.com or your regional endpoint, several validation steps occur:

- End-entity certificate (issued to quantum.cloud.ibm.com)

- Intermediate CA certificate (issued by IBM's certificate authority)

- Root CA certificate (trusted by your operating system's certificate store)

- Verifying each certificate's digital signature using the next certificate in the chain

- Confirming the domain name (quantum.cloud.ibm.com) matches the certificate's Subject Alternative Name (SAN) extension

- Checking the certificate hasn't expired

- Verifying the root CA is in your operating system's trusted store

- Confirming the certificate isn't on a revocation list (OCSP stapling)

Use our Certificate Decoder to inspect certificate details and our SSL Checker to verify certificate configurations.

If any validation fails, your client refuses connection, protecting you from phishing and man-in-the-middle attacks targeting quantum computing credentials.

Why IBM Quantum Is Transitioning to Post-Quantum Cryptography

IBM is implementing quantum-safe TLS (QS-TLS) because current TLS algorithms (RSA, ECC) are vulnerable to attacks by future quantum computers. A sufficiently powerful quantum computer running Shor's algorithm could decrypt all data encrypted with classical algorithms in minutes. IBM has already begun implementing post-quantum TLS on IBM Quantum Platform, using NIST-standardized post-quantum algorithms:

This transition occurs in phases, progressively extending quantum-safe protection through additional layers of the platform. Your quantum computing work submitted today may be stored for years; quantum-safe encryption ensures it remains protected against future quantum threats.

Part 2: Preparing Your Environment for IBM Quantum SSL/TLS

System Requirements for Proper TLS Support

Before connecting to IBM Quantum Platform, verify your environment supports modern TLS:

For Qiskit Python Environments:

# Check your Python version (3.8 or later required)

import sys

print(f"Python version: {sys.version}")

# Verify OpenSSL version (1.1.1 or later required)

import ssl

print(f"OpenSSL version: {ssl.OPENSSL_VERSION}")

# Check installed Qiskit packages

# Run: pip list | grep qiskit

Minimum system requirements:

For REST API Clients (curl, Node.js, Java, etc.):

Verify TLS support with curl:

# Test TLS 1.2 and 1.3 support

curl --tlsv1.2 https://quantum.cloud.ibm.com/api/v1/usage -I

curl --tlsv1.3 https://quantum.cloud.ibm.com/api/v1/usage -I

# Check certificate chain

curl -v https://quantum.cloud.ibm.com/api/v1/usage 2>&1 | grep "certificate"

Verifying Operating System Certificate Stores

Your operating system maintains a certificate store containing trusted root CAs. IBM's certificate chain must validate against roots in this store.

On macOS/Linux:

# List trusted root certificates

# macOS

system_profiler SPSecureElementDetails | grep -i certificate

# Linux - check default CA store locations

ls -la /etc/ssl/certs/

ls -la /etc/pki/ca-trust/extracted/pem/

# Search for IBM's trusted root CA

grep -r "IBM" /etc/pki/ca-trust/ 2>/dev/null

# Update CA certificates on Linux

sudo update-ca-trust

On Windows:

# View certificate store via PowerShell

Get-ChildItem Cert:\LocalMachine\Root | Where-Object {$_.Subject -like "IBM"}

# Update Windows certificate store (automatic via Windows Update)

# Manual update: Settings > Update & Security > View optional updates

Python-specific certificate verification:

import ssl

import certifi

# Show default certificate store location

print(certifi.where())

# Verify certificate bundle exists

import os

ca_bundle = certifi.where()

print(f"CA bundle exists: {os.path.exists(ca_bundle)}")

print(f"CA bundle size: {os.path.getsize(ca_bundle)} bytes")

If your system lacks proper root CA certificates, Qiskit and HTTP clients will fail with SSL certificate verification errors. Most systems have these pre-installed, but isolated or highly-controlled environments may require manual CA updates.

Part 3: Installing and Configuring Qiskit with SSL/TLS Support

Setting Up Qiskit Runtime with Proper Certificate Validation

Step 1: Install Qiskit Components

# Create isolated Python environment (recommended)

python -m venv qiskit_env

source qiskit_env/bin/activate # On Windows: qiskit_env\Scripts\activate

# Install Qiskit Runtime with latest TLS/SSL support

pip install qiskit qiskit-ibm-runtime --upgrade

# Verify installation

python -c "import qiskit; print(qiskit.__version__)"

python -c "import qiskit_ibm_runtime; print(qiskit_ibm_runtime.__version__)"

Step 2: Generate and Secure Your IBM Cloud API Key

Access IBM Quantum Platform and generate a 44-character API key:

Critical security note: Your API key grants full access to your quantum computing resources. Treat it like a password, not like a public authentication token.

Step 3: Save Credentials in a Trusted Environment

For personal workstations and trusted development environments, save your credentials locally using Qiskit's credential manager:

from qiskit_ibm_runtime import QiskitRuntimeService

# Securely save credentials (executed once)

QiskitRuntimeService.save_account(

token="",

name="my_ibm_quantum", # Optional friendly name

instance="ibm-q/open/main", # Default instance

region="us-south", # Or your preferred region

set_as_default=True,

overwrite=True

)

print("Credentials saved successfully")

Under the hood, this command:

Step 4: Connect to IBM Quantum Platform with Automatic TLS Validation

from qiskit_ibm_runtime import QiskitRuntimeService, Sampler

from qiskit import QuantumCircuit

import numpy as np

# Initialize service (loads TLS certificates automatically)

service = QiskitRuntimeService(name="my_ibm_quantum")

# Get quantum backend

backend = service.least_busy(operational=True, simulator=False)

print(f"Connected to: {backend.name}")

# Create simple quantum circuit

qc = QuantumCircuit(2, 2)

qc.h(0) # Hadamard gate

qc.cx(0, 1) # CNOT gate

qc.measure([0, 1], [0, 1])

# Execute on quantum backend with secure TLS connection

with Sampler(session=backend) as sampler:

# TLS encrypts this communication

result = sampler.run(qc, shots=100).result()

counts = result.quasi_dists[0].binary_probabilities()

print(f"Measurement results: {counts}")

When you run this code, Qiskit performs:

If certificate validation fails, Qiskit raises an ssl.SSLError with details about the validation failure.

Troubleshooting Certificate Verification Errors

Error: "SSL: CERTIFICATE_VERIFY_FAILED"

This error occurs when Qiskit cannot validate IBM Quantum's SSL certificate:

ssl.SSLError: _ssl.c:1125: error:1416D086:SSL routines:tls_process_server_certificate_verify:certificate verify failed

Diagnosis:

import ssl

import certifi

import requests

# Check certificate validity

try:

response = requests.get(

'https://quantum.cloud.ibm.com/api/v1/usage',

verify=True # Enforce certificate validation

)

print(f"Certificate validation successful: {response.status_code}")

except requests.exceptions.SSLError as e:

print(f"Certificate validation failed: {e}")

Common causes and solutions:

```bash

# Update certificate bundle

pip install --upgrade certifi

python -m certifi

```

```bash

# Sync system clock

# macOS/Linux

sudo ntpdate -s time.nist.gov

# Windows

w32tm /resync

```

- Contact your network administrator

- Some enterprises use SSL inspection, requiring custom CA configuration

- Temporarily disable SSL scanning in antivirus settings

- Or configure your antivirus to trust IBM's CA

Solution for corporate environments with custom CAs:

# Use custom CA bundle if required by your organization

import os

from qiskit_ibm_runtime import QiskitRuntimeService

# Set custom CA bundle path

os.environ['REQUESTS_CA_BUNDLE'] = '/path/to/corporate-ca-bundle.pem'

os.environ['SSL_CERT_FILE'] = '/path/to/corporate-ca-bundle.pem'

# Now initialize service with corporate CA chain

service = QiskitRuntimeService(name="my_ibm_quantum")

Part 4: Securing REST API Connections to IBM Quantum

Understanding IBM Quantum REST API Authentication Flow

Unlike Qiskit SDK connections (which handle TLS transparently), REST API connections require explicit certificate and authentication management. The REST API flow is:

Critical requirement: All requests must go over TLS 1.2+ on port 443 (HTTPS). HTTP (port 80) connections are rejected.

Configuring curl for IBM Quantum REST API

Basic REST API authentication:

# Step 1: Generate bearer token from API key

API_KEY="your-44-character-api-key"

# Request token from IBM Cloud IAM service (TLS-encrypted)

TOKEN_RESPONSE=$(curl -X POST "https://iam.cloud.ibm.com/identity/token" \

-H "Content-Type: application/x-www-form-urlencoded" \

-d "grant_type=urn:ibm:params:oauth:grant-type:apikey&apikey=${API_KEY}" \

2>/dev/null)

# Extract bearer token (valid for 1 hour)

BEARER_TOKEN=$(echo $TOKEN_RESPONSE | python -c "import sys, json; print(json.load(sys.stdin)['access_token'])")

echo "Bearer token obtained"

# Step 2: Query IBM Quantum API with bearer token

# This request is protected by TLS encryption

curl -X GET "https://quantum.cloud.ibm.com/api/v1/usage" \

-H "Authorization: Bearer ${BEARER_TOKEN}" \

-H "Accept: application/json" \

-v # Add -v to see TLS handshake details

Understanding the curl output for TLS verification:

* Trying 104.93.xxx.xxx:443...

* Connected to quantum.cloud.ibm.com (104.93.xxx.xxx) port 443

* ALPN: curl offers h2,http/1.1

* TLSv1.3 (OUT), TLS handshake, Client Hello (1):

* TLSv1.3 (IN), TLS handshake, Server Hello (2):

* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):

* TLSv1.3 (IN), TLS handshake, Certificate (11):

* TLSv1.3 (IN), TLS handshake, Certificate verify (15):

* TLSv1.3 (IN), TLS handshake, Finished (20):

* TLSv1.3 (OUT), TLS handshake, Finished (20):

* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384

* ALPN: server accepted h2

* Server certificate:

subject: CN=.cloud.ibm.com

* start date: Dec 1 2024 00:00:00 GMT

* expire date: Dec 31 2025 23:59:59 GMT

* issuer: CN=IBM Secure Services Intermediate CA,OU=Secure Services,O=International Business Machines,C=US

* SSL certificate verify ok.

Key indicators of successful TLS:

Advanced curl options for certificate control:

# Show complete certificate chain

curl --cacert /path/to/ca-bundle.pem \

https://quantum.cloud.ibm.com/api/v1/usage

# Pin certificate to prevent MITM even if CA is compromised

curl --cert-status \

--pinnedpubkey 'sha256//abcdef1234567890...' \

https://quantum.cloud.ibm.com/api/v1/usage

# Force specific TLS version

curl --tlsv1.3 https://quantum.cloud.ibm.com/api/v1/usage

# Disable cert verification only for development (NEVER use in production)

curl -k https://quantum.cloud.ibm.com/api/v1/usage # INSECURE - don't use

Implementing TLS in Python REST Clients

Using the requests library (recommended):

import requests

import json

from datetime import datetime, timedelta

class IBMQuantumRestClient:

"""Secure REST client for IBM Quantum Platform with TLS/SSL handling"""

def __init__(self, api_key: str):

self.api_key = api_key

self.bearer_token = None

self.token_expiry = None

self.session = requests.Session()

# Critical: Enforce TLS certificate verification

self.session.verify = True # Default, but explicit for clarity

# Use system certificate store (certifi)

import certifi

self.session.verify = certifi.where()

def _get_bearer_token(self) -> str:

"""Exchange API key for bearer token via secure TLS connection"""

# All communication with IAM is TLS-encrypted

response = requests.post(

'https://iam.cloud.ibm.com/identity/token',

headers={'Content-Type': 'application/x-www-form-urlencoded'},

data=f'grant_type=urn:ibm:params:oauth:grant-type:apikey&apikey={self.api_key}',

verify=True # Enforce certificate validation

)

if response.status_code != 200:

raise Exception(f"Token generation failed: {response.text}")

token_data = response.json()

self.bearer_token = token_data['access_token']

# Token expires after expires_in seconds (typically 3600 = 1 hour)

expires_in = token_data.get('expires_in', 3600)

self.token_expiry = datetime.now() + timedelta(seconds=expires_in)

return self.bearer_token

def _refresh_token_if_needed(self):

"""Refresh token if expired"""

if self.bearer_token is None or datetime.now() >= self.token_expiry:

self._get_bearer_token()

def api_request(self, method: str, endpoint: str, kwargs) -> dict:

"""Make authenticated API request with TLS certificate validation"""

self._refresh_token_if_needed()

url = f'https://quantum.cloud.ibm.com/api/v1/{endpoint}'

headers = {

'Authorization': f'Bearer {self.bearer_token}',

'Accept': 'application/json'

}

# TLS certificate verification is enforced here

response = self.session.request(

method,

url,

headers=headers,

verify=True, # Enforce certificate validation

kwargs

)

if response.status_code >= 400:

raise Exception(f"API error {response.status_code}: {response.text}")

return response.json() if response.text else {}

def get_usage(self) -> dict:

"""Query usage statistics"""

return self.api_request('GET', 'usage')

def list_backends(self) -> list:

"""List available quantum backends"""

return self.api_request('GET', 'backends')

# Usage example

try:

client = IBMQuantumRestClient(api_key='your-api-key')

usage = client.get_usage()

print(f"Usage: {usage}")

backends = client.list_backends()

print(f"Available backends: {[b['name'] for b in backends]}")

except requests.exceptions.SSLError as e:

print(f"SSL/TLS certificate validation failed: {e}")

print("Verify your system CA certificates are up-to-date")

except requests.exceptions.ConnectionError as e:

print(f"Connection failed: {e}")

print("Check IBM Quantum endpoint accessibility and firewall rules")

Configuring Node.js/JavaScript REST Clients

Using axios with explicit TLS configuration:

const axios = require('axios');

const https = require('https');

const fs = require('fs');

// Create HTTPS agent with TLS configuration

const httpsAgent = new https.Agent({

ca: fs.readFileSync('/etc/ssl/certs/ca-certificates.crt'), // System CA bundle

rejectUnauthorized: true, // Enforce certificate validation

minVersion: 'TLSv1.2', // Require TLS 1.2+

ciphers: 'HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK', // Strong ciphers only

});

class IBMQuantumClient {

constructor(apiKey) {

this.apiKey = apiKey;

this.bearerToken = null;

this.tokenExpiry = null;

// Create axios instance with TLS agent

this.client = axios.create({

httpsAgent: httpsAgent,

timeout: 30000, // 30 second timeout

});

}

async getBearerToken() {

try {

const response = await axios.post(

'https://iam.cloud.ibm.com/identity/token',

grant_type=urn:ibm:params:oauth:grant-type:apikey&apikey=${this.apiKey},

{

headers: {'Content-Type': 'application/x-www-form-urlencoded'},

httpsAgent: httpsAgent, // Use TLS agent

}

);

this.bearerToken = response.data.access_token;

this.tokenExpiry = Date.now() + (response.data.expires_in * 1000);

return this.bearerToken;

} catch (error) {

throw new Error(Token generation failed: ${error.message});

}

}

async ensureValidToken() {

if (!this.bearerToken || Date.now() >= this.tokenExpiry) {

await this.getBearerToken();

}

}

async apiRequest(method, endpoint) {

await this.ensureValidToken();

try {

const response = await this.client({

method: method,

url: https://quantum.cloud.ibm.com/api/v1/${endpoint},

headers: {

'Authorization': Bearer ${this.bearerToken},

'Accept': 'application/json'

}

});

return response.data;

} catch (error) {

if (error.code === 'CERT_HAS_EXPIRED' || error.code === 'UNABLE_TO_VERIFY_LEAF_SIGNATURE') {

throw new Error(TLS Certificate verification failed: ${error.message});

}

throw error;

}

}

async getUsage() {

return this.apiRequest('GET', 'usage');

}

}

// Usage

(async () => {

try {

const client = new IBMQuantumClient('your-api-key');

const usage = await client.getUsage();

console.log('Usage:', usage);

} catch (error) {

console.error('API error:', error.message);

}

})();

Part 5: Advanced TLS Configuration and Monitoring

Firewall and Network Configuration for TLS Connections

By default, IBM Quantum Platform connections go through the public internet. For production quantum computing workloads, you can optionally configure firewall rules:

Allowed endpoints (whitelist these for outbound HTTPS):

# Primary endpoints

quantum.cloud.ibm.com:443

auth.quantum-computing.ibm.com:443

# Regional endpoints (if using specific regions)

quantum.cloud-ibm-eu.de:443 # Europe (Frankfurt)

quantum.cloud-ibm-us-south.ibm.com:443 # US South

# IAM authentication endpoint

iam.cloud.ibm.com:443

# Certificate revocation checking (OCSP)

ocsp.cloud.ibm.com:443

iptables example for Linux firewall:

# Allow outbound HTTPS to IBM Quantum endpoints

sudo iptables -A OUTPUT -d quantum.cloud.ibm.com -p tcp --dport 443 -j ACCEPT

sudo iptables -A OUTPUT -d iam.cloud.ibm.com -p tcp --dport 443 -j ACCEPT

# Block all other HTTPS (defense in depth)

sudo iptables -A OUTPUT -p tcp --dport 443 -j REJECT

# Verify rules

sudo iptables -L OUTPUT -n

Testing connectivity to required endpoints:

# Test TLS connectivity to all required endpoints

for endpoint in quantum.cloud.ibm.com auth.quantum-computing.ibm.com iam.cloud.ibm.com; do

echo "Testing $endpoint:443..."

openssl s_client -connect $endpoint:443 -tls1_3 < /dev/null 2>&1 | grep -E "Verify|Connected|CN="

done

Inspecting TLS Handshake with openssl

Detailed certificate inspection:

# Connect and retrieve certificate

openssl s_client -connect quantum.cloud.ibm.com:443 -showcerts < /dev/null > ibm_quantum_cert.pem

# Decode certificate to human-readable format

openssl x509 -in ibm_quantum_cert.pem -text -noout

# Check certificate validity dates

openssl x509 -in ibm_quantum_cert.pem -noout -dates

# Verify certificate chain

openssl verify -CAfile /etc/ssl/certs/ca-certificates.crt ibm_quantum_cert.pem

# Check certificate fingerprint (for pinning)

openssl x509 -in ibm_quantum_cert.pem -noout -fingerprint -sha256

Use our Certificate Decoder for a user-friendly way to inspect certificate details without using command-line tools.

Simulating client TLS behavior:

# Verbose TLS handshake with debug output

openssl s_client -connect quantum.cloud.ibm.com:443 \

-tls1_3 \

-showcerts \

-servername quantum.cloud.ibm.com # Send SNI

# Test specific cipher suite

openssl s_client -connect quantum.cloud.ibm.com:443 \

-cipher 'TLS_AES_256_GCM_SHA384' # Test specific strong cipher

# Check for Perfect Forward Secrecy

openssl s_client -connect quantum.cloud.ibm.com:443 -tlsextdebug < /dev/null 2>&1 | \

grep -i "supported signature algs"

Monitoring and Logging TLS Connections

Python logging for TLS debugging:

import logging

import http.client

# Enable HTTP client debugging (shows TLS details)

http.client.HTTPConnection.debuglevel = 1

logging.basicConfig(level=logging.DEBUG)

logger = logging.getLogger('urllib3.connectionpool')

logger.setLevel(logging.DEBUG)

# Now requests will show TLS handshake details

import requests

response = requests.get('https://quantum.cloud.ibm.com/api/v1/usage')

Monitoring certificate expiration (critical for uptime):

import ssl

import socket

from datetime import datetime, timedelta

def check_certificate_expiration(hostname, port=443):

"""Alert if certificate expires within 30 days"""

context = ssl.create_default_context()

with socket.create_connection((hostname, port), timeout=10) as sock:

with context.wrap_socket(sock, server_hostname=hostname) as ssock:

cert = ssock.getpeercert()

# Extract expiration date

cert_expires = datetime.strptime(

cert['notAfter'],

'%b %d %H:%M:%S %Y %Z'

)

days_until_expiration = (cert_expires - datetime.now()).days

print(f"Certificate expires: {cert_expires}")

print(f"Days until expiration: {days_until_expiration}")

if days_until_expiration < 30:

print(f"WARNING: Certificate expires in {days_until_expiration} days!")

return False

return True

# Monitor IBM Quantum certificate

check_certificate_expiration('quantum.cloud.ibm.com')

For automated monitoring of your own SSL certificates, use our SSL Expiry Reminder feature to receive email alerts before certificates expire.

Corporate proxy and SSL inspection handling:

If your organization uses corporate proxies that intercept SSL connections:

# Configure proxy with certificate validation

import requests

from requests.auth import HTTPProxyAuth

proxies = {

'https': 'https://proxy.corporate.com:8443'

}

# If proxy requires authentication

proxies_auth = HTTPProxyAuth('username', 'password')

# Add corporate CA to trusted store

import certifi

ca_bundle = '/path/to/corporate-ca-bundle.pem'

response = requests.get(

'https://quantum.cloud.ibm.com/api/v1/usage',

proxies=proxies,

auth=proxies_auth,

verify=ca_bundle # Validate against corporate CA + system roots

)

Part 6: Post-Quantum Cryptography Transition

Understanding IBM's Quantum-Safe TLS Initiative

IBM is implementing quantum-safe TLS because current cryptographic algorithms (RSA-2048, ECC) will be vulnerable to quantum computers. The transition follows a phased approach:

Phase 1 (Currently in progress): Quantum-safe TLS at client-to-platform boundary

Phase 2 (Planned): Quantum-safe cryptography throughout IBM Cloud infrastructure

Phase 3 (Future): Pure post-quantum cryptography (no classical fallback)

NIST Post-Quantum Cryptography Standards

ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism) — FIPS 203

Replaces Diffie-Hellman and ECDH for key exchange:

ML-DSA (Module-Lattice-Based Digital Signature Algorithm) — FIPS 204

Replaces RSA and ECDSA for authentication:

SLH-DSA (Stateless Hash-based Digital Signature Algorithm) — FIPS 205

Alternative signature algorithm for specialized use cases:

Preparing Your Applications for Post-Quantum TLS

Current status (as of late 2024):

Your Qiskit and REST API connections to IBM Quantum already benefit from hybrid post-quantum TLS:

# Your current code automatically uses quantum-safe TLS

from qiskit_ibm_runtime import QiskitRuntimeService

service = QiskitRuntimeService()

# TLS connection automatically negotiates quantum-safe parameters

No code changes required — IBM Quantum Platform transparently handles the post-quantum transition.

For future-proofing your infrastructure:

Checking which TLS algorithms are negotiated:

import ssl

import socket

def get_negotiated_tls_parameters(hostname, port=443):

"""Determine which TLS algorithms server negotiated"""

context = ssl.create_default_context()

with socket.create_connection((hostname, port), timeout=10) as sock:

with context.wrap_socket(sock, server_hostname=hostname) as ssock:

# Get cipher info

cipher = ssock.cipher()

print(f"Negotiated TLS version: {cipher[1]}")

print(f"Cipher suite: {cipher[0]}")

# Protocol version

print(f"SSL/TLS version: {ssock.version()}")

get_negotiated_tls_parameters('quantum.cloud.ibm.com')

# Example output:

# Negotiated TLS version: TLSv1.3

# Cipher suite: TLS_AES_256_GCM_SHA384

# SSL/TLS version: TLSv1.3

Part 7: Security Best Practices for IBM Quantum

Certificate Pinning for Enhanced Security

Certificate pinning prevents man-in-the-middle attacks even if a CA is compromised. While the full implementation requires custom adapters, understanding the concept is important for high-security environments:

import subprocess

# Get certificate hash for pinning

cert_hash = subprocess.check_output([

'openssl', 's_client', '-connect', 'quantum.cloud.ibm.com:443',

'-servername', 'quantum.cloud.ibm.com',

], input=b'\n').decode()

print("Certificate retrieved for pinning analysis")

Secure API Key Management

Never commit API keys to version control:

# WRONG - never do this

API_KEY = "IBMxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" # Bad!

# RIGHT - use environment variables

import os

api_key = os.environ.get('IBM_QUANTUM_TOKEN')

if not api_key:

raise ValueError("IBM_QUANTUM_TOKEN environment variable not set")

Set secure environment variable:

# Store in ~/.bashrc or ~/.zshrc (restricted to your user)

export IBM_QUANTUM_TOKEN="your-44-character-key"

# Or use OS-level secure storage

# macOS: Keychain

security add-generic-password -s "ibm-quantum" -a "api-key" -w "your-key"

# Linux: Secret Service

python -c "import keyring; keyring.set_password('ibm-quantum', 'api-key', 'your-key')"

Retrieve from secure storage in Python:

import keyring

import os

# Method 1: Environment variable

api_key = os.environ.get('IBM_QUANTUM_TOKEN')

# Method 2: OS keyring

if not api_key:

try:

api_key = keyring.get_password('ibm-quantum', 'api-key')

except:

pass

if not api_key:

raise ValueError("API key not found in environment or keyring")

from qiskit_ibm_runtime import QiskitRuntimeService

service = QiskitRuntimeService(token=api_key)

Credential Rotation and Revocation

Rotate API keys regularly (monthly recommended):

Immediately revoke compromised keys:

If you accidentally expose your API key:

Testing Your TLS Configuration

Comprehensive TLS security test:

from qiskit_ibm_runtime import QiskitRuntimeService

import requests

import ssl

import socket

def test_quantum_tls_configuration():

"""Validate TLS security configuration for IBM Quantum"""

print("=== IBM Quantum TLS Security Test ===\n")

# Test 1: Basic connectivity

print("1. Testing HTTPS connectivity...")

try:

response = requests.get(

'https://quantum.cloud.ibm.com/api/v1/usage',

timeout=10,

verify=True

)

print(f" ✓ HTTPS connection successful (HTTP {response.status_code})")

except requests.exceptions.SSLError as e:

print(f" ✗ SSL/TLS error: {e}")

return False

# Test 2: TLS version check

print("\n2. Checking TLS version...")

context = ssl.create_default_context()

with socket.create_connection(('quantum.cloud.ibm.com', 443), timeout=10) as sock:

with context.wrap_socket(sock, server_hostname='quantum.cloud.ibm.com') as ssock:

tls_version = ssock.version()

print(f" ✓ Connected with {tls_version}")

if tls_version not in ['TLSv1.2', 'TLSv1.3']:

print(f" ⚠ Warning: {tls_version} is acceptable but upgrade to TLSv1.3 recommended")

# Test 3: Certificate validation

print("\n3. Validating certificate...")

try:

cert = requests.get(

'https://quantum.cloud.ibm.com',

verify=True,

timeout=10

)

print(" ✓ Certificate validation passed")

except requests.exceptions.SSLError:

print(" ✗ Certificate validation failed")

return False

# Test 4: Qiskit connectivity

print("\n4. Testing Qiskit Runtime Service...")

try:

service = QiskitRuntimeService()

backend = service.least_busy(operational=True, simulator=False)

print(f" ✓ Successfully connected to {backend.name}")

except Exception as e:

print(f" ✗ Qiskit connection failed: {e}")

return False

print("\n=== All TLS tests passed ===")

return True

# Run test

test_quantum_tls_configuration()

Part 8: Troubleshooting Common TLS Issues

SSL Certificate Verification Failures

Issue: ssl.SSLError: certificate verify failed

Root causes:

Solutions:

# Update CA certificates

pip install --upgrade certifi

# Check system time

date # Should match current time

# Update system time if needed

sudo ntpdate -s time.nist.gov # Linux/macOS

w32tm /resync # Windows

# Test DNS resolution

nslookup quantum.cloud.ibm.com

# Verify DNS returns correct IP

ping quantum.cloud.ibm.com

Connection Timeouts

Issue: Connection times out, no response from server

Likely cause: Firewall blocking outbound HTTPS traffic

Solutions:

# Test connectivity to IBM Quantum

curl -v https://quantum.cloud.ibm.com/api/v1/usage --max-time 10

# Test with verbose output

# Look for which step times out (DNS, connection, TLS handshake, etc.)

# Test from another network if available

# If it works on mobile hotspot but not office network,

# your corporate firewall is blocking the connection

# Contact your network administrator to whitelist:

# - quantum.cloud.ibm.com port 443

# - auth.quantum-computing.ibm.com port 443

# - iam.cloud.ibm.com port 443

Token Expiration and Bearer Token Errors

Issue: 401 Unauthorized or "token has expired"

Root cause: Bearer token expires after 1 hour

Solution (Qiskit handles this automatically):

# Qiskit automatically refreshes tokens, but if you're using REST API:

from qiskit_ibm_runtime import QiskitRuntimeService

service = QiskitRuntimeService()

# Service manages token refresh internally

# For REST API, manually refresh:

import time

token_expiry = None

def get_fresh_token(api_key):

global token_expiry

# Refresh if expired or expiring within 5 minutes

if token_expiry is None or (token_expiry - time.time()) < 300:

response = requests.post(

'https://iam.cloud.ibm.com/identity/token',

headers={'Content-Type': 'application/x-www-form-urlencoded'},

data=f'grant_type=urn:ibm:params:oauth:grant-type:apikey&apikey={api_key}'

)

token_data = response.json()

token = token_data['access_token']

token_expiry = time.time() + token_data['expires_in']

return token

return None # Still valid

Qiskit-Specific SSL Issues

Issue: ssl.SSLError in Qiskit Python environment

# Diagnose the issue

import ssl

import certifi

from qiskit_ibm_runtime.api.session import Session

# Check certificate store

print(f"CA bundle: {certifi.where()}")

# Check OpenSSL version

print(f"OpenSSL version: {ssl.OPENSSL_VERSION}")

# Test direct SSL connection

import socket

context = ssl.create_default_context()

context.load_verify_locations(certifi.where())

try:

with socket.create_connection(('quantum.cloud.ibm.com', 443), timeout=10) as sock:

with context.wrap_socket(sock, server_hostname='quantum.cloud.ibm.com') as ssock:

print("SSL connection successful")

except ssl.SSLError as e:

print(f"SSL error: {e}")

# Update certifi and try again

import subprocess

subprocess.check_call(['pip', 'install', '--upgrade', 'certifi'])

Conclusion

Securing your IBM Quantum Platform connections with SSL/TLS is fundamental to protecting your quantum algorithms, computational results, and credentials. This guide has provided a comprehensive framework for:

IBM Quantum's phased transition to quantum-safe TLS ensures your quantum computing workloads remain secure against future threats. By following these best practices—maintaining updated certificates, validating credentials, rotating API keys regularly, and monitoring TLS connections—you create a robust security foundation for your quantum computing applications.

For more SSL/TLS security resources, explore our SSL Tools for certificate verification and management, or browse our Learning Hub for additional security guides.