REF-24: DevTest4 cert refresh + REST WSP OCES3 migration - #52
Open
thomasnymand wants to merge 5 commits into
Open
REF-24: DevTest4 cert refresh + REST WSP OCES3 migration#52thomasnymand wants to merge 5 commits into
thomasnymand wants to merge 5 commits into
Conversation
The DevTest4 STS TLS certificate rotated from the Sectigo RSA DV / UserTrust chain to the new Sectigo Public Server Authentication hierarchy, and the STS token-signing certificate (NemLog-in IdP - Test) expired 2026-03-12. Both broke the SOAP/REST scenarios at the WSC->STS call (No X509TrustManager / PKIX path building failed / expired token signer). - ssl-trust.jks (9 files): add Sectigo Public Server Authentication CA DV R36 (intermediate) + Root R46 as trust anchors, so the DevTest4 STS TLS endpoint validates. Anchoring at the CA (not the pinned leaf) survives future leaf rotations. - trust.jks (8 files): replace the expired 'sts' alias with the renewed NemLog-in IdP - Test signing cert (valid 2025-08-20 .. 2028-08-19). Verified with a live JSSE handshake against SecureTokenService.test-devtest4-nemlog-in.dk using the updated ssl-trust.jks. The legacy LBSB / ADFS (TRUST2408) truststores were left untouched (different, retired STS identity).
…anchors
The rest-service mutual-TLS client-auth truststore (ssl-trust.jks) still
pinned only the OCES2 / TRUST2408 test CAs, so it rejected the OCES3
client certificate (CN=OIOIDWS.Java WSC - Test, issued by Den Danske
Stat OCES udstedende-CA 1) with a TLS 'bad_certificate' alert during the
WSC->WSP handshake.
- Add the OCES3 CA chain (Den Danske Stat OCES udstedende-CA 1 + rod-CA)
as trust anchors.
- Remove the retired OCES2 anchors (TRUST2408 Systemtest XIX/XXII/XXXIV),
which are no longer active.
Verified: rest-service restarted with the OCES3-only truststore now
completes the mTLS handshake (the request reaches AuthorizationService).
A separate, pre-existing token-decryption error ('Key is too long for
unwrapping') remains in the REST flow and is unrelated to trust.
… trust)
The REST WSP (rest-service) still carried OCES2 material, so token
validation failed after the mTLS fix:
- service.pfx held an expired OCES2 keypair (OIO IDWS Java ref. WSP,
expired 2024-02-03); the STS encrypts the assertion for the WSP's
current OCES3 cert, so RSA key-unwrap failed ('Key is too long for
unwrapping'). Replace it with the registered OCES3 WSP keypair
(OIOIDWS.Java WSP - Test, valid to 2026-11-13) — the same one the SOAP
service-hok/service-bearer WSPs already use.
- sts-trust.jks held only retired ADFS STS certs, so the assertion's
signature could not be verified ('Unable to evaluate key against
signature'). Replace with the current OCES3 STS signing cert
(NemLog-in IdP - Test, valid to 2028-08-19).
Verified: integrationtest/rest-signature RestSignatureScenarioJavaTest
now passes end-to-end (Java WSC -> STS -> Java REST WSP).
The rest-service spring-boot-maven-plugin had no version, so Maven resolved the latest (3.x) build, which is compiled for Java 17 and fails under the project's JDK 8 with UnsupportedClassVersionError on 'mvn spring-boot:run'. Pin it to 2.2.11.RELEASE, matching the Spring Boot line used and runnable on Java 8. Verified: plain 'mvn spring-boot:run' now starts rest-service on JDK 8.
thomasnymand
changed the title
The bootstrap WSC still carried OCES2/ADFS certs (client cert, STS trust and WSP trust all expired 2022-2024). Bring them to OCES3 parity with the working SOAP scenarios, swapping the certs under the EXISTING aliases so all cxf.xml / *.properties wiring is preserved (no config changes): - client.pfx: OCES3 WSC keypair (OIOIDWS.Java WSC - Test, -> 2026-11-13) kept under alias 'oio idws java ref. wsc (funktionscertifikat)' (referenced by ws-security.signature.username and client.properties). - trust.jks 'sts' + 'devtest4-sts': OCES3 STS signing cert (NemLog-in IdP - Test, -> 2028); used by ws-security.encryption.username and sts.properties. - trust.jks 'server': OCES3 WSP cert (OIOIDWS.Java WSP - Test). Sourced from the verified-working scenarios (WSC keypair from system-user-scenario-java; WSP cert from service-hok; STS cert as in the rest of REF-24). Not runnable here for end-to-end verification: the bootstrap flow needs browser SSO plus an interactive MOCES password and is @ignore'd. ssl-trust.jks already got the R36/R46 DevTest4 TLS anchors earlier in REF-24.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
REF-24: DevTest4 certificate refresh + REST WSP OCES3 migration
The DevTest4 SOAP and REST scenarios were failing at multiple points because certificates behind the DevTest4 STS and the REST WSP had rotated (TLS chain change + OCES2→OCES3 migration). This PR refreshes all of them and gets the Java scenarios working end-to-end on JDK 8.
1. STS transport TLS chain —
ssl-trust.jks(9 files)The DevTest4 STS TLS cert moved from the Sectigo RSA DV / UserTrust RSA chain to the new Sectigo Public Server Authentication hierarchy. Symptom:
No X509TrustManager implementation available→PKIX path building failed.2. STS signing cert —
trust.jks(8 files)CN=NemLog-in IdP - Test(Den Danske Stat OCES) expired 2026-03-12.stsalias with the renewed cert (valid 2025-08-20 → 2028-08-19); old cert fully removed.3. REST WSP (
rest-service) OCES3 migrationThe REST WSP still carried OCES2 material and failed token validation in three successive layers, each fixed:
ssl-trust.jks— client-auth truststore trusted only OCES2/TRUST2408 CAs, rejecting the OCES3 client cert (bad_certificate). Added the OCES3 CA chain (Den Danske Stat OCES udstedende-CA 1+rod-CA); removed the retired OCES2 anchors.service.pfx— held an expired OCES2 keypair (OIO IDWS Java ref. WSP, expired 2024-02-03), so RSA key-unwrap failed (Key is too long for unwrapping). Replaced with the registered OCES3 WSP keypair (OIOIDWS.Java WSP - Test, valid to 2026-11-13) — the same keypair the SOAPservice-hok/service-bearerWSPs use.sts-trust.jks— held only retired ADFS STS certs, so assertion signature verification failed (Unable to evaluate key against signature). Replaced with the current OCES3 STS signing cert.4. SOAP
bootstrap-scenario— OCES3 (IDWS layer)The bootstrap WSC still carried OCES2/ADFS certs (client cert, STS trust, WSP trust — expired 2022–2024). Brought to OCES3 parity with the working SOAP scenarios, swapping certs under the existing aliases so all
cxf.xml/*.propertieswiring is preserved (no config changes):client.pfx→ OCES3 WSC keypair (OIOIDWS.Java WSC - Test), kept under aliasoio idws java ref. wsc (funktionscertifikat)(used bysignature.username/client.properties).trust.jkssts+devtest4-sts→ OCES3 STS signing cert (used byencryption.username=sts/sts.properties);server→ OCES3 WSP cert.ssl-trust.jksalready got the R36/R46 DevTest4 TLS anchors (change 1).Not end-to-end verified: the bootstrap flow needs browser SSO + an interactive MOCES password and is
@Ignored. The certs were sourced from the verified-working scenarios. The OIOSAML SP/SSO layer (SP + IdP metadata, SP signing keystore, NemLog-in registration) is still on the retired ADFS era and is out of scope here — tracked as a separate follow-up issue.5. Build — pin
spring-boot-maven-pluginto2.2.11.RELEASEThe plugin had no version, so Maven resolved a 3.x (Java 17) build that fails under the project's JDK 8 with
UnsupportedClassVersionErroronmvn spring-boot:run. Pinned to a Java-8-compatible version.Verification (JDK 8)
SecureTokenService.test-devtest4-nemlog-in.dksucceeds with the updatedssl-trust.jks.system-user-javaandsignature-scenario-javaintegration tests pass (WSC → STS → Java WSP).RestSignatureScenarioJavaTestpasses end-to-end (WSC → STS → Java REST WSP) after the three OCES3 fixes above.mvn spring-boot:runnow startsrest-serviceon JDK 8.Scope / notes
.NETWSP (dotnetalias in the.NET-facingssl-trust.jksfiles) were intentionally kept; only the dead OCES2 CA anchors inrest-servicewere removed..NET-WSP test variants (system-user-dotnet,rest-signature-dotnet) are unaffected here — they need the.NETWSPs from the separateOIOIDWS.dotnetrepo.Commits
b9bf021— DevTest4 STS TLS chain (R36/R46) + renewedstssigning cert3bbd561— REST client-auth OCES3 CA + OCES2-anchor removale75286c— REST WSP OCES3 keypair (service.pfx) + STS trust (sts-trust.jks)668f36f— pinspring-boot-maven-plugin(JDK 8)aaa2a0b— SOAPbootstrap-scenarioIDWS-layer OCES3 migration (client.pfx,trust.jks)