Skip to content

Updated config template to allow FIPS mode - #1054

Closed
pawelziel wants to merge 1 commit into
OpenIdentityPlatform:masterfrom
pawelziel:patch-1
Closed

pawelziel wants to merge 1 commit into
OpenIdentityPlatform:masterfrom
pawelziel:patch-1

Conversation

@pawelziel

Copy link
Copy Markdown

Updated config template:

  • disable (weak) PKCS5S2 password storage scheme
  • set (strong) wrapping for Crypto Manager
    to allow installation in FIPS 140-3 compliant environment.

Updated config template:
 - disable (weak) PKCS5S2 password storage scheme
 - set (strong) wrapping for Crypto Manager
to allow installation in FIPS 140-3 compliant environment.
@vharseko

Copy link
Copy Markdown
Member

Code review

Found 2 issues:

  1. ds-cfg-key-wrapping-transformation: RSA/ECB/PKCS1Padding is a downgrade, not a "strong" wrapping, and it re-introduces the exact value Fix java/rsa-without-oaep CodeQL alert by dropping the RSA PKCS#1 v1.5 fallback #776 removed. The server default is RSA/ECB/OAEPWITHSHA-1ANDMGF1PADDING (CryptoManagerConfiguration.xml#L197-L201). RSA-OAEP is the SP 800-56B key-transport scheme that FIPS 140-3 accepts; RSA PKCS#1 v1.5 key transport is disallowed by NIST SP 800-131A Rev. 2 since 2024 and is what CodeQL reports as java/rsa-without-oaep (CWE-780) — which is why Fix java/rsa-without-oaep CodeQL alert by dropping the RSA PKCS#1 v1.5 fallback #776 dropped it from the setup fallback and left the comment "must not be used to wrap the CryptoManager secret keys" (ConfigureDS.java#L1334-L1342). The template applies to every new installation, FIPS or not, and CryptoManagerImpl.isConfigurationChangeAcceptable only checks the alg/mode/padding shape plus Cipher.getInstance, so nothing rejects it. If your provider does not register the OAEP-SHA-1 spelling, the place to handle that is the existing ConfigureDS.updateCryptoCipher() fallback (another OAEP variant, e.g. RSA/ECB/OAEPWithSHA-256AndMGF1Padding) or a per-deployment dsconfig set-crypto-manager-prop --set key-wrapping-transformation:..., not PKCS#1 v1.5 in the shared template. The CI "Test on Unix FIPS" job sets up and starts the server with the BCFIPS provider against the unchanged template (build.yml#L204-L244), so it would help to say which provider / java.security setup actually rejected the default.

cn: Crypto Manager
ds-cfg-ssl-cert-nickname: ads-certificate
ds-cfg-ssl-encryption: false
ds-cfg-key-wrapping-transformation: RSA/ECB/PKCS1Padding

  1. Disabling cn=PKCS5S2 removes the scheme for every new install without fixing what fails under FIPS. It is not weaker than the still-enabled cn=PBKDF2: both call SecretKeyFactory.getInstance("PBKDF2WithHmacSHA1"). The only difference in initialization is the hard-coded SecureRandom.getInstance("SHA1PRNG") (PKCS5S2PasswordStorageScheme.java#L86-L92, and again at L247-L251), which FIPS-only providers do not register, whereas AbstractPBKDF2PasswordStorageScheme uses new SecureRandom() (L77-L81). Switching PKCS5S2 to the same keeps it usable. As proposed, a disabled scheme is never registered (PasswordStorageSchemeConfigManager.java#L102-L108), so any {PKCS5S2} value — the Atlassian-migration case the scheme exists for, and which the 2.8.0 upgrade task still adds enabled (Upgrade.java#L145-L154) — can no longer bind on a fresh install. PKCS5S2PasswordStorageSchemeTestCase.testAuthPKCS5S2Passwords and the inherited testSettingEncodedPassword bind end-to-end through a server started from resource/config, so they will fail with this change (PKCS5S2PasswordStorageSchemeTestCase.java#L112-L118). The admin guide would also go stale (chap-pwd-policy.adoc#L795-L797).

objectClass: ds-cfg-pkcs5s2-password-storage-scheme
cn: PKCS5S2
ds-cfg-java-class: org.opends.server.extensions.PKCS5S2PasswordStorageScheme
ds-cfg-enabled: false

@vharseko vharseko added packaging deb/rpm/MSI, distribution layout, config.ldif security Security fixes / CodeQL code-scanning alerts fips FIPS 140 mode: BC-FIPS provider, BCFKS keystores, approved algorithms labels Sep 16, 2026
@vharseko

Copy link
Copy Markdown
Member

#1058 addresses what this PR works around, without changing the template:

  • PKCS5S2 stays enabled and initializes from the provider's default SecureRandom instead of asking for SHA1PRNG by name — the lookup a FIPS-restricted JCE fails — and its initialization failure now names the missing algorithm.
  • setup warns when the runtime supports no RSA-OAEP spelling and names the key-wrapping-transformation property to set before the first start; the crypto manager's refusal at start names it too; the install guide gets a procedure for a FIPS 140 runtime (setup --doNotStartldifmodifystart-ds), with the caveat about PKCS#1 v1.5. The bundled BC-FIPS provider offers RSA-OAEP, so with it the default configuration works as it is.
  • A FIPS-approved key transport for a SunPKCS11-only runtime is tracked in Crypto manager: a FIPS-approved key transport for JVMs whose only RSA cipher is PKCS#1 v1.5 (SunPKCS11) #1056.

Unless your installation failed for a reason the two findings above do not cover — the exact error from logs/server.out would tell — I suggest closing this PR in favour of #1058.

@pawelziel pawelziel closed this Sep 16, 2026
vharseko added a commit to vharseko/OpenDJ that referenced this pull request Sep 23, 2026
PKCS5S2PasswordStorageScheme asked for SecureRandom "SHA1PRNG" by name, at
initialization and again in the offline encoder. A FIPS-restricted JCE
(SunPKCS11-NSS-FIPS, BC-FIPS) registers no such algorithm, so the scheme
threw a message-less InitializationException and the server refused to
start — the failure OpenIdentityPlatform#1054 works around by disabling the scheme in the
config template, which would also stop {PKCS5S2} hashes imported from
Atlassian products from binding on every new installation.

Take the provider's default SecureRandom instead, as the PBKDF2 family
already does, and let the InitializationException of both PKCS5S2 and the
PBKDF2 schemes name the algorithm that is missing rather than leaving the
administrator with no reason for the failed start. The SHA1PRNG constant
has no user left and goes.

The tests withdraw the providers which register the service — SUN for
SHA1PRNG, with BC-FIPS standing in for the digests, SunJCE for
PBKDF2WithHmacSHA1 — run the scheme without them, and put them back.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

fips FIPS 140 mode: BC-FIPS provider, BCFKS keystores, approved algorithms packaging deb/rpm/MSI, distribution layout, config.ldif security Security fixes / CodeQL code-scanning alerts

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants