There IS only one signature on an X.509 certificate.
But there can be multiple different certificates for a given CA, and multiple different verification paths using DIFFERENT certificates, with one signature on each certificate. That's what Qualys/ssllabs shows you (when detected).
Usually the CA involved will document this; one of my favorites for ...
You can look up TLS magic numbers on the TLS parameter registry, including alerts. 40 is “handshake failure”, which doesn't tell you much.
The reason for the handshake failure is clearly indicated in the server output: “no shared cipher”.
Below command is given in client to connect with using same cipher and port mentioned in server
Well, no. You did not ...
found the answer in a related post Missing X509 extensions with an openssl-generated certificate
I needed to add -extensions v3_req to the signing request
openssl x509 -extensions v3_req\
-signkey my-private-key.pem \
-in my.csr \
-req -days 365 -out my-public-key-cert.pem -extfile ssl.ext
You're not far off - copy_extensions is not an extension, it needs to be in the CA_Default section to instruct the CA to copy extensions from the CSR to the signed certificate.
Example below, see the last line:
[ CA_default ]
# Directory and file locations.
dir = /home/ca
certs = $dir/certs
crl_dir = $dir/crl
For this to work you need to use a CA and make it trusted. If you control and secure the CA key pair, you can be more confident that others won't sign certs with your CA.
Your idea of creating the CA then deleting (I would suggest shredding instead) would fit your purpose. If others need to trust the CA you created for the product to work on their devices, ...