Email validation failed - RestAPI createUser - ErrorCode: TA40048

Products

• CA Strong Authentication

Issue/Introduction

An issue is observed for the user creation via RestAPI. However, if it were possible to have the .war updated so that it can also accept TLDs longer than 6 characters? It looks like the domain is longer than what is accepted:

2025-12-12 11:01:46,729 [[ACTIVE] ExecuteThread: '14' for queue: 'weblogic.kernel.Default (self-tuning)'] INFO  tenant.service.TenantUserService(254) [] -> Entered in createTenantUser Service.

2025-12-12 11:01:46,729 [[ACTIVE] ExecuteThread: '14' for queue: 'weblogic.kernel.Default (self-tuning)'] INFO  tenant.service.TenantUserService(272) [] -> [EMAIL_VALIDATION] Starting email validation in RestAPI createTenantUser endpoint. OrgName: GUEST, Email: [email protected]

2025-12-12 11:01:46,729 [[ACTIVE] ExecuteThread: '14' for queue: 'weblogic.kernel.Default (self-tuning)'] INFO  advauth.util.Validator(129) [] -> [EMAIL_VALIDATION] Entering RestAPI email validation with exception throwing. Method: validateEmailAndThrowAPIExceptionIfFailed

2025-12-12 11:01:46,729 [[ACTIVE] ExecuteThread: '14' for queue: 'weblogic.kernel.Default (self-tuning)'] INFO  advauth.util.Validator(130) [] -> [EMAIL_VALIDATION] Email to validate: [email protected], Locale: en_US

2025-12-12 11:01:46,729 [[ACTIVE] ExecuteThread: '14' for queue: 'weblogic.kernel.Default (self-tuning)'] INFO  advauth.util.Validator(82) [] -> [EMAIL_VALIDATION] Entering RestAPI email validation. Method: validateEmail

2025-12-12 11:01:46,729 [[ACTIVE] ExecuteThread: '14' for queue: 'weblogic.kernel.Default (self-tuning)'] INFO  advauth.util.Validator(83) [] -> [EMAIL_VALIDATION] Email to validate: <EMAIL>

2025-12-12 11:01:46,729 [[ACTIVE] ExecuteThread: '14' for queue: 'weblogic.kernel.Default (self-tuning)'] INFO  advauth.util.Validator(84) [] -> [EMAIL_VALIDATION] Regex pattern used (RestAPI): \b[\p{Alnum}._'%+-]+@(?:[\p{Alnum}-]+\.)+[\p{Alpha}]{2,6}\b

2025-12-12 11:01:46,729 [[ACTIVE] ExecuteThread: '14' for queue: 'weblogic.kernel.Default (self-tuning)'] DEBUG advauth.util.Validator(87) [] -> [EMAIL_VALIDATION] Email is not null/empty, proceeding with regex matching

2025-12-12 11:01:46,729 [[ACTIVE] ExecuteThread: '14' for queue: 'weblogic.kernel.Default (self-tuning)'] INFO  advauth.util.Validator(91) [] -> [EMAIL_VALIDATION] Regex match result: false for email: <EMAIL>

2025-12-12 11:01:46,729 [[ACTIVE] ExecuteThread: '14' for queue: 'weblogic.kernel.Default (self-tuning)'] WARN  advauth.util.Validator(93) [] -> [EMAIL_VALIDATION] Email validation FAILED - email does not match regex pattern: <EMAIL>

2025-12-12 11:01:46,729 [[ACTIVE] ExecuteThread: '14' for queue: 'weblogic.kernel.Default (self-tuning)'] INFO  advauth.util.Validator(98) [] -> [EMAIL_VALIDATION] Exiting RestAPI email validation. Method: validateEmail, Result: false

2025-12-12 11:01:46,729 [[ACTIVE] ExecuteThread: '14' for queue: 'weblogic.kernel.Default (self-tuning)'] ERROR advauth.util.Validator(135) [] -> [EMAIL_VALIDATION] Email validation FAILED - throwing ApiException. Email: <EMAIL>, ErrorCode: TA40048

2025-12-12 11:01:46,729 [[ACTIVE] ExecuteThread: '14' for queue: 'weblogic.kernel.Default (self-tuning)'] ERROR advauth.util.Validator(136) [] -> Email validation failed.Given phone number is <EMAIL>

Environment

CA Strong Authentication

Cause

As per the existing validation pattern configured in the system, only TLDs with 2 to 6 characters are permitted.

Resolution

The issue is reviewed and confirmed that this behavior is expected based on the current email validation rules.

The email address is being rejected because the Top-Level Domain (TLD) length exceeds the allowed limit. As per the existing validation pattern configured in the system, only TLDs with 2 to 6 characters are permitted. Since the provided email domain contains a longer TLD, the validation fails and user creation via the REST API is rejected.

The issue has been taken into consideration to accept TLDs longer than 6 characters in CP2 release. and the release is planned at the end of January 2026 tentatively.