Add option to select RSA or ECDSA key type when creating certificates

[KalebCheng]

Summary

This PR introduces an option to select the key type (RSA or ECDSA) when creating SSL/TLS certificates in Nginx Proxy Manager. Previously, only ECDSA keys were generated by default, which limited flexibility for users who prefer RSA keys.

Changes

• Updated the certificate creation UI to include a dropdown for key type selection.
• Updated backend certificate generation logic to support RSA keys alongside ECDSA.
• Ensured backward compatibility: existing ECDSA-only workflows remain unchanged.

Motivation

Some users prefer RSA keys for compatibility reasons or specific security requirements. This change allows users to choose between RSA and ECDSA when generating certificates.

Testing

• Tested creating both RSA and ECDSA certificates.
• Verified that generated certificates are valid and correctly installed in Nginx Proxy Manager.
• Confirmed that existing ECDSA-only workflows are unaffected.

[nginxproxymanagerci]

Docker Image for build 1 is available on DockerHub:

nginxproxymanager/nginx-proxy-manager-dev:pr-5121

Note

Ensure you backup your NPM instance before testing this image! Especially if there are database changes.
This is a different docker image namespace than the official image.

Warning

Changes and additions to DNS Providers require verification by at least 2 members of the community!

[jc21]

Great stuff, thanks :)

[CamelT0E]

@KalebCheng,
good work-very nice!
Maybe the key length can still be changed in dropdown menu?
RSA: 2048 (default), 3072, 4096 or 8192
ECDSA: 256 (default), 384 or 521

The German BSI recommends the use of RSA-3072, which roughly corresponds to ECDSA-256. RSA-2048 should not be used beyond 2030.

[KalebCheng]

@KalebCheng, good work-very nice! Maybe the key length can still be changed in dropdown menu? RSA: 2048 (default), 3072, 4096 or 8192 ECDSA: 256 (default), 384 or 521

The German BSI recommends the use of RSA-3072, which roughly corresponds to ECDSA-256. RSA-2048 should not be used beyond 2030.

Great suggestion !

This feature was initially created just to solve a problem I encountered during my own usage, but your proposal makes a lot of sense. I’ll implement it.