Forwarded to devs Certificate assignment fails with "Permission denied" when logged in as customer (works as admin)

[nethubonline]

Username:

TITLE

Certificate assignment fails with "Permission denied" when logged in as customer (works as admin)

PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE

Plesk Obsidian 18.0.80.7, AlmaLinux 9.4 x86_64

PROBLEM DESCRIPTION

When assigning an uploaded or self-signed SSL/TLS certificate to a domain's hosting via Hosting & DNS > Hosting > Certificate, Plesk returns "Permission denied" and the certificate is not saved/assigned.

This only occurs when logged in as the customer (subscription owner). Performing the same steps while logged in as admin works correctly with no error.

STEPS TO REPRODUCE

1. Create a customer account:

plesk bin customer --create example.com -name "example.com" -passwd "ComplexPassword@123"

1. Create a subscription:

plesk bin subscription --create example.com -owner example.com -service-plan "Plan 1" -ip 1.2.3.4 -login ftp_example -passwd "ComplexPassword@123"

1. Log in to Plesk as example.com.
2. Go to Dashboard > SSL/TLS Certificates > Manage > Add SSL/TLS Certificate, and either generate a self-signed certificate or upload a certificate.
3. Go to Hosting & DNS > Hosting > Certificate, select the self-signed/uploaded certificate, and click Save.

ACTUAL RESULT

Error: Permission denied. (Only reproducible as customer; admin can perform the same action successfully.)

EXPECTED RESULT

The selected certificate should be saved and assigned to the domain's hosting without error.

ANY ADDITIONAL INFORMATION

(DID NOT ANSWER QUESTION)

YOUR EXPECTATIONS FROM PLESK SERVICE TEAM

Confirm bug

 

[Sebahat.hadzhi]

Thank you for the report, @nethubonline . The issue is caused by the lack of the "Hosting settings management" permission. You can grath the prmission for the service plan and sync, or by individually customizing the subscription. Once grated you should be able to assign the certificate.

We already have an internal task under which the behavior is being investigated by our engineers. I will follow up once we get confirmation on whether this is recognized as a bug or expected behavior.