Jupyter server fails to start: ssl.SSLError [ASN1: NOT_ENOUGH_DATA] loading Windows certificates

Symptoms

Starting a Jupyter notebook in PyCharm on Windows fails with the notification "Jupyter server process exited with code 1". The traceback ends with an SSL error raised while Python loads certificates from the Windows certificate store:

File "...\envs\myenv\lib\site-packages\tornado\netutil.py", line 35, in <module>
    _client_ssl_defaults = ssl.create_default_context(ssl.Purpose.SERVER_AUTH)
File "...\envs\myenv\lib\ssl.py", line 753, in create_default_context
    context.load_default_certs(purpose)
File "...\envs\myenv\lib\ssl.py", line 577, in load_default_certs
    self._load_windows_store_certs(storename, purpose)
File "...\envs\myenv\lib\ssl.py", line 569, in _load_windows_store_certs
    self.load_verify_locations(cadata=certs)
ssl.SSLError: [ASN1: NOT_ENOUGH_DATA] not enough data (_ssl.c:4192)

The failure can be intermittent (the same environment starts on some attempts) and typically affects one conda or virtual environment while others on the same machine work. A closely related variant of the same problem reports ssl.SSLError: [ASN1] nested asn1 error.

Environment

• Customer type: Personal and commercial customers
• Region affected: All regions
• Product affected: PyCharm (any JetBrains IDE with Jupyter support), Windows

Cause

The error comes from Python, not from the IDE. On Windows, Python's ssl module loads all certificates from the system certificate store in a single batch (_load_windows_store_certs). If one certificate in the store cannot be parsed by the environment's OpenSSL, the whole batch fails and the Jupyter server process exits during startup. This is a known CPython limitation: python/cpython#104135.

Two factors commonly combine to trigger it:

• A malformed or truncated certificate appears in the Windows certificate store. On centrally managed machines, certificates are pushed by IT tooling, so store contents change over time. This also explains intermittent failures.
• The OpenSSL library bundled with the environment's Python is strict about ASN.1 parsing. Recent OpenSSL 3.5.7 builds reject certificates that 3.5.6 and earlier tolerated. Environments with older Python versions (for example, 3.9) and different OpenSSL builds can fail while newer environments (for example, Python 3.12 in the conda base env) keep working.

Note: the pyOpenSSL package version is unrelated. The relevant component is the OpenSSL library linked into the environment's Python (python -c "import ssl; print(ssl.OPENSSL_VERSION)").

Resolution

1. Confirm the problem is independent of the IDE. In a Command Prompt:

conda activate <env-name>
python -m jupyterlab

The same SSL error outside the IDE confirms an environment-level cause.

2. Check the OpenSSL version in the failing and in a working environment:

python -c "import ssl; print(ssl.OPENSSL_VERSION)"

3. If the failing environment has OpenSSL 3.5.7, downgrade it:

conda install -n <env-name> openssl=3.5.6

4. If the OpenSSL version is not the differentiator, inspect the Windows certificate store (certmgr.msc for the user store, certlm.msc for the machine store) for malformed or truncated entries and remove them. On company-managed machines, involve the IT department, since the store is centrally provisioned.

5. As a durable alternative, recreate the environment with a newer Python version, which bundles a more tolerant OpenSSL build.