feat: add support for selecting SSL key type (ECDSA/RSA)

[mnr73]

Added the ability to specify the SSL key type (ECDSA or RSA) for each site in the Nginx Proxy Manager. This enhancement is particularly useful for environments with IoT devices that have limitations with specific key types, such as RSA-only support. The implementation includes:

• Backend support for storing and validating the ssl_key_type field.
• Swagger schema updated to validate the new input.
• Frontend update to allow users to select the SSL key type via a dropdown menu.

This feature ensures greater flexibility and compatibility in managing SSL certificates for diverse setups.

#3354

[mnr73]

it's work truly :)

[jc21]

Great work. Do you happen to have any automated commands that might test the feature? ie:

1. I request a ECDSA cert and run a console command to check it given I only have the HTTPS URL
2. I request a RSA cert and run a console command to check it given I only have the HTTPS URL

[mnr73]

Thanks. Yes I think could be test with nmap but I work on Diffie-Hellman cipher support and another problem that we had for IOT devices. after that I add some automated test for this.

Please hold on while I complete these.

[mnr73]

This pull request introduces features specifically designed to address common challenges with Embedded and IoT devices. The following updates have been made:

• Encryption Key Selection: Added the ability to choose between RSA and ECDSA encryption keys for each domain to enhance flexibility and security.
• Extended Cipher Suites: Included additional cipher suites to support a broader range of IoT devices.
• Support for Diffie-Hellman Parameters: Integrated cipher suites for stronger and more secure communications.
• Default Server Selection: Added the capability to designate a default server from existing hosts for simpler configuration and better management.

related issues

• #2539
• #3354
• #2147
• #951

[mnr73]

the result supported ciphers

PORT    STATE SERVICE
443/tcp open  https
| ssl-enum-ciphers:
|   TLSv1.2:
|     ciphers:
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_128_CCM (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_128_CCM_8 (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_256_CCM (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_256_CCM_8 (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 2048) - A
|       TLS_DHE_RSA_WITH_ARIA_128_GCM_SHA256 (dh 2048) - A
|       TLS_DHE_RSA_WITH_ARIA_256_GCM_SHA384 (dh 2048) - A
|       TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (dh 2048) - A
|       TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA256 (dh 2048) - A
|       TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (dh 2048) - A
|       TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA256 (dh 2048) - A
|       TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (dh 2048) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_ARIA_128_GCM_SHA256 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_ARIA_256_GCM_SHA384 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_CAMELLIA_128_CBC_SHA256 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_CAMELLIA_256_CBC_SHA384 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (secp256r1) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_CCM (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_CCM_8 (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - A
|       TLS_RSA_WITH_AES_256_CCM (rsa 2048) - A
|       TLS_RSA_WITH_AES_256_CCM_8 (rsa 2048) - A
|       TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A
|       TLS_RSA_WITH_ARIA_128_GCM_SHA256 (rsa 2048) - A
|       TLS_RSA_WITH_ARIA_256_GCM_SHA384 (rsa 2048) - A
|       TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_CAMELLIA_128_CBC_SHA256 (rsa 2048) - A
|       TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_CAMELLIA_256_CBC_SHA256 (rsa 2048) - A
|     compressors:
|       NULL
|     cipher preference: client
|_  least strength: A

Nmap done: 1 IP address (1 host up) scanned in 33.33 seconds

[mnr73]

Great work. Do you happen to have any automated commands that might test the feature? ie:

1. I request a ECDSA cert and run a console command to check it given I only have the HTTPS URL
2. I request a RSA cert and run a console command to check it given I only have the HTTPS URL

with this command we can see what is the SSL key type. rsa or ecdsa

nmap --script ssl-cert -p 443 example.com

or can use this command with openssl

openssl s_client -connect example.com:443 </dev/null 2>/dev/null | openssl x509 -noout -text | grep "Public Key Algorithm"

[jc21]

Nice. I'll look at adding this in the next release, after the one I'm about to do today.

[mnr73]

I think there is a problem in auto test. i test in local every thing was Ok. also revert all commit but it fail again.

[nginxproxymanagerci[bot]]

Docker Image for build 22 is available on DockerHub as nginxproxymanager/nginx-proxy-manager-dev:pr-4218

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

[localhost14]

When will this be implemented?

[Lure5134]

@jc21 Is there anything we can do for this pr so it gets merged?

[grzywek]

@mnr73 hello, I tested nginxproxymanager/nginx-proxy-manager-dev:pr-4218

I believe to maintain consistency, option to select SSL Key Type should be also visible while creating certificate from the Certificates tab:

Maybe we should include the key type in the table to have a clear distinction:

and also here:

Thanks - that PR already helped me much 😊

[cyberdust2k]

Is this still in the scope for a future release? I've been relying on this branch for having RSA on my IOT endpoint for a while now. Anything needing to be done here?

[leiax00]

How's this feature coming along? Why hasn't it been merged yet? Is any additional work required?

[cyberfox]

Can I help get this landed? I have several older model servers (Dell PowerEdge R630 and R730) whose iDRAC can only take RSA certs, and I want to use the certs from NPM in the iDRAC. Putting NPM in front of the iDRAC causes it to have trouble reaching it's own resources. I've temporarily worked around it by generating a second set of certs for the iDRAC services, and setting it with racadm, but I'd like to not be generating two different sets of certs, and optimally re-using the high quality NPM cert refresh process.

[mnr73]

Hi @jc21. Please check this PR again and let me know if there’s anything that should be added or updated. thanks.