[PR #120] [MERGED] fix(sharepoint): use SHA-1 thumbprint in the x5t assertion header #118

New issue

Closed

opened 2026-10-18 21:14:30 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-18 21:14:30 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/open-webui/oikb/pull/120
Author: @a-nych
Created: 9/16/2026
Status: ✅ Merged
Merged: 9/16/2026
Merged by: @tjbck

Base: main ← Head: fix/sharepoint-cert-thumbprint-sha1

📝 Commits (1)

9564dff fix(sharepoint): use SHA-1 thumbprint in the x5t assertion header

📊 Changes

1 file changed (+5 additions, -3 deletions)

View changed files

📝 src/oikb/connectors/sharepoint.py (+5 -3)

📄 Description

Certificate auth is currently unusable with any certificate signed with SHA-256, which in practice is every certificate people generate today.

_get_token_via_certificate builds the JWT x5t header from the certificate's signature hash algorithm:

thumbprint = cert.fingerprint(cert.signature_hash_algorithm or x509.hashes.SHA256())

For a sha256WithRSAEncryption certificate that yields a 32-byte digest. The Microsoft identity platform identifies the registered key by its SHA-1 thumbprint, regardless of how the certificate is signed (certificate credentials spec), so the token request is rejected:

AADSTS700027: The certificate with identifier used to sign the client assertion is not
registered on application. [Reason - The key was not found.,
Thumbprint of key used by client: '9D14CB20887023...']

The thumbprint in that message is the SHA-256 digest, which never matches what Entra stored.

Verified against a live Entra app registration: same key, same certificate, same assertion, only the x5t digest swapped from SHA-256 to SHA-1 — 401 becomes an issued token, and a full SharePoint library sync then runs.

x509.hashes in the old fallback also isn't a real attribute, so that branch would have raised AttributeError had signature_hash_algorithm ever been None. Both go away here.

Note this is unrelated to certificate strength — SHA-1 is only the identifier Entra indexes keys by; the assertion itself is still signed RS256.

🤖 Generated with Claude Code

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/open-webui/oikb/pull/120 **Author:** [@a-nych](https://github.com/a-nych) **Created:** 9/16/2026 **Status:** ✅ Merged **Merged:** 9/16/2026 **Merged by:** [@tjbck](https://github.com/tjbck) **Base:** `main` ← **Head:** `fix/sharepoint-cert-thumbprint-sha1` --- ### 📝 Commits (1) - [`9564dff`](https://github.com/open-webui/oikb/commit/9564dff5993e2b79bfd720f81c6433e44d9f1575) fix(sharepoint): use SHA-1 thumbprint in the x5t assertion header ### 📊 Changes **1 file changed** (+5 additions, -3 deletions) <details> <summary>View changed files</summary> 📝 `src/oikb/connectors/sharepoint.py` (+5 -3) </details> ### 📄 Description Certificate auth is currently unusable with any certificate signed with SHA-256, which in practice is every certificate people generate today. `_get_token_via_certificate` builds the JWT `x5t` header from the certificate's *signature* hash algorithm: ```python thumbprint = cert.fingerprint(cert.signature_hash_algorithm or x509.hashes.SHA256()) ``` For a `sha256WithRSAEncryption` certificate that yields a 32-byte digest. The Microsoft identity platform identifies the registered key by its **SHA-1** thumbprint, regardless of how the certificate is signed ([certificate credentials spec](https://learn.microsoft.com/en-us/entra/identity-platform/certificate-credentials)), so the token request is rejected: ``` AADSTS700027: The certificate with identifier used to sign the client assertion is not registered on application. [Reason - The key was not found., Thumbprint of key used by client: '9D14CB20887023...'] ``` The thumbprint in that message is the SHA-256 digest, which never matches what Entra stored. Verified against a live Entra app registration: same key, same certificate, same assertion, only the `x5t` digest swapped from SHA-256 to SHA-1 — 401 becomes an issued token, and a full SharePoint library sync then runs. `x509.hashes` in the old fallback also isn't a real attribute, so that branch would have raised `AttributeError` had `signature_hash_algorithm` ever been `None`. Both go away here. Note this is unrelated to certificate strength — SHA-1 is only the identifier Entra indexes keys by; the assertion itself is still signed RS256. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi

2026-10-18 21:14:30 +00:00

closed this issue
added the
pull-request
label

No labels

pull-request

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

open-webui/oikb#118

No description provided.

Rows
Columns