Yes, I would still check those values. Changing the browser language only tested the client side, while Tomcat may be running with different JVM locale settings. In IIQ, open:
https://<your-IIQ-host>/identityiq/debug
Go to wrench icon > About and note:
user.language
user.country
java.locale.providers
I would test one change at a time in a lower environment or maintenance window, since these settings affect the complete IIQ JVM. If user.language and user.country show French, temporarily add:
-Duser.language=en -Duser.country=US
Restart Tomcat and test again. If the error remains and you are using JDK 17, restore the original settings and separately test:
-Djava.locale.providers=COMPAT,CLDR
If either test resolves it, we will know whether the JVM locale or the CLDR locale provider is triggering the invalid date pattern. If neither works, then the locale can probably be ruled out and the failure is within IIQ’s processPrivateKeyInfo() processing.
@ameniii IT looks like Java version compatibility issue between IIQ 8.5 P1 and the Java runtime you’re using. Could you please what is the version of Java you are using?
Thanks, Ameni. user.language=fr shows that the Tomcat JVM default language is French. Not finding java.locale.providers means it was not explicitly configured. On JDK 17, the default provider order is CLDR,COMPAT.
That makes the JVM locale a strong lead, but we still need the test to confirm it. Could you temporarily add this to Tomcat JAVA_OPTS or CATALINA_OPTS:
-Duser.language=en -Duser.country=US
Restart Tomcat, confirm under About that the values changed to en and US, then test the connection again. If the same error remains, restore those settings and separately test:
-Djava.locale.providers=COMPAT,CLDR
I would make these changes in a lower environment or maintenance window since they affect the full IIQ JVM.
Java 17 is supported for IIQ 8.5, so I would not change the Java version based on this error alone. The stack trace specifically shows an invalid date pattern reaching SimpleDateFormat inside processPrivateKeyInfo().
May I know what is the impact of changing the value of these parameters as you suggested please? knowing that I will test the change on a low environment, but I still want to understand what would this impact.
Yes, the SharePoint Online connector documentation you referenced is the correct documentation for IIQ 8.5p1.
The error Illegal pattern character 'j' is typically a Java date format parsing error. In most cases, a field expected to contain a date format is receiving an invalid value, certificate information, or JSON content that IIQ is trying to parse as a date pattern.
Things to check:
Verify all date/time format fields in the application configuration, especially if any customizations were made.
Review the Application Debug logs (identityiq.log) and capture the full stack trace. The stack trace will identify the exact field causing the exception.
Confirm the certificate upload was successful and that no certificate metadata is being placed in a field expecting a date pattern.
Check whether the client secret, certificate thumbprint, tenant ID, and application ID are entered in the correct fields.
If you copied values from JSON (App Registration manifest), ensure no JSON content was pasted into a field expecting a simple string.
Try creating a brand-new application definition and re-entering the configuration manually to rule out corrupted application metadata.
If you can share the full stack trace from identityiq.log (not just the UI error), it will be much easier to pinpoint the exact configuration element causing the Illegal pattern character 'j' exception
Hello Vikas, thanks for your reply. But we found out that the error is not related to missing/incoherent fields of the configuration. There’s also no date field required in the config. The error is due to date format processing in the background but it’s not clear what this processing is exactly, not sure if it’s really a date that was parsed or something that was considered as a date