31

"Handshake failure" means the handshake failed, and there is no SSL/TLS connection. You should see that openssl exits to the shell (or CMD etc) and does not wait for input data to be sent to the server. "Verify return code 0" means that no problem was found in the server's certificate, either because it wasn't checked at all or because it was checked and was ...


18

Finally, I have pinned down the root cause of the problem. There were two problems with my setup. a) For two-way SSL, the certificate signed by the Intermediate CA must have clientAuth in extendedKeyUsage (Thanks to @dave_thompson_085) which can be verified by the below command $ openssl x509 -in /path/to/client/cert -noout -purpose | grep 'SSL client :' ...


8

This is a wildcard certificate and is valid only for third levels such as name.company.com and not fourth levels as the desired bitbucket.kl.company.com You need to use another certificate for either the specific domain name or get a wildcard one for *.kl.company.com


6

As the error message already explains: the servers certificate cannot be authenticated with the known CA certificates from the CAfile: /etc/pki/tls/certs/ca-bundle.crt (as the server certificate is issued by a CA unknown to your system). Two fairly common reasons for such a message: The certificate is really signed by an unknown CA (for instance an ...


5

The ssl.ca-file reads the content, you can call any file type here, even a .txt it doesn't matter for lighttpd if the content is a certificate or a certificate chain. When you enable ssl.verifyclient.activate, the lighttpd will request certificate that has sing by root CA certificate(s) inside of ca-file. If I want to use a 3rd-party certificate, for ...


5

It turned out that there was at least one enabled virtual host which was bound to 443 port and didn't have ssl configured properly (ssl_certificate_key, ssl_certificate parameters were lacking). I don't know why, but nginx didn't complain about this and instead - other virtual hosts were broken.


5

This looks more like a problem where you have improperly installed the new certificate, so that only the server certificate is provided in the TLS handshake but not the intermediate certificate(s). Browser will usually successfully try to work around such misconfiguration and fill in the missing chain certificates themselves while other client don't. Please ...


4

Your configuration line doesn't contain the expected hyphen (-). It instead contains an en dash (–). It looks similar, but it's a completely different character. In fact, it appears both of them are en dashes. This can happen if you copy and paste from a web site which has unhelpfully changed hyphens to en dashes. To solve the problem, replace both of the ...


4

Both work fine in Chrome on W10. On Firefox I get the following error "parts of this page are not secure (such as images). For example, this link. Firefox is often fussier about certificates and chains. Update - the core reason for the error is because there's a missing certificate in the chain. See this page, or this page.


4

Yes, the warnings are because you redirect to an IP address but the certificate is for a domain name. This can't work like this, as the two don't match naturally ... Why do you even do this? This looks terrible unprofessional ...


4

check if the entry is correct If you run keytool --list -keystore <yourkeystore> then you should get back a PrivateKeyEntry, somthing like that: tomcat, Aug 23, 2018, PrivateKeyEntry, Certificate fingerprint (SHA-256): F2:BA:29:E... import the certificate If you have a signed certificate and private key, then you have to export them to a PKCS12 ...


4

At the time of writing this, example.net used a certificate signed by the DigiCert SHA2 Secure Server CA intermediate CA, which in turn is signed by the DigiCert Global Root CA root CA. Both CA certificates use a 2048-bit RSA key. However, if you are behind a corporate TLS proxy, the actual CA might only use a 1024-bit key (you didn't provide any details on ...


3

If I understand correctly, you currently have a PFX and are looking to import into a Linux machine. A PFX file is a Windows based file format for a password protected key and certificate bundle. It may also include the whole cert chain. The openSSL command you should need is openssl pkcs12 -in keyStore.pfx -out keyStore.pem -nodes Give that a try and see ...


3

Browsers, such as Internet Explorer/Edge, Chrome and Safari will look at the AIA extensions's caIssuer field for an URL from where it can download a superior CA's certificate if one is not provided by the server during the TLS handshake. Your website's certificate has a caIssuer field set to http://ssl.trustwave.com/issuers/OVCA2_L1.crt therefore all the ...


3

The same Common Name and key can be used in different certificate files to offer multiple paths to certify: Path 1 (your browser considered this path, because the server sent that intermediate) The website certificate, signed by: Go Daddy Secure Certificate Authority - G2, signed by: Go Daddy Root Certificate Authority - G2, signed by: Go Daddy Class 2 ...


3

Your CA is not adding the extensions requested in the CSR to the signed certificate. When OpenSSL creates a certificate without an extension, it marks it as a version 1 certificate. Have a look at the copy_extensions option, which should be placed in the section pointed to by the default_ca option. Specifically, set it to copy or copyall (preferably the ...


2

After running the SSL Server test on SSL Labs, you will find a section called Handsake Simulation It should look something like this, if a client isn't supported it will list a reason why. For example on this server IE8 on XP is not supported because it doesn't support SNI


2

This has already been answered on SO. From https://stackoverflow.com/questions/28072021/discrepancy-between-openssl-verify-and-s-client-command openssl verify doesn't expect the certificate to contain its chain. Chain needs to be passed with -untrusted argument. You can pass the same file there, trust is still determined by finding a trusted root in ...


2

The answer came from a Comodo knowledge base article: Untrusted Certificate Error on Android. The cause of the error is the existing Comodo certificates in the default Windows certificate store. One of the intermediate certificates, the COMODO RSA Certification Authority, is present by default in the Trusted Root Certification Authorities folder as a self-...


2

The strongSwan Android app enforces that the configured server address/hostname is contained in the certificate as subjectAltName. If that's not the case you have to configure the server identity manually in the VPN profile, either to a subjectAltName that's actually contained in the certificate (if the server finds a config with that identity) or to the ...


2

The CA-signed certificate was supposed to be in PEM/Base64 format. It was rather in DER format. Changing it fixed the problem.


2

Your certificate is only valid for *.angelsense.com. It is not valid for angelsense.com. To use it without any subdomain you have to add angelsense.com additionally to *.angelsense.com as a SAN (Subject Alternative Name) when you create the certificate.


2

I would give a try to an online tool like: ssllabs ssltest. Another similar tool can be found on Digicert home page.


2

Yes, it is correct. Your browser opens a connection with a server and asks for a TLS negotiation. Via SNI, gives a hints on what is the wanted site. Apache doesn't have a configured certificated for that, and "randomly" chooses (actually, pick the first configured) a certificate for the connection. Only after the connection is established the browser can ...


2

I have found an answer. FTPS server admin updated me additional information. The server is configured for explicit AT-TLS. So below commands did the job for me: lftp -u us15030,******** ftp://bldbmsa.boulder.ibm.com set ftp:ssl-force true set ftp:ssl-protect-data true set ssl:ca-file "/etc/ssl/certs/ca-certificates.crt" get /tmp/ttt.txt.gz Just FYI: ...


2

Credit to SSLMate for the great explanation. Basically the AddTrust External CA Root certificate is now surplus to requirements, and as of May 30th 2020, that's the certificate that just expired. There are likely other certificates in your CA bundle which could be used to verify the main certificate you have, but older software (OpenSSL 1.0 and the like) is ...


2

You are using a wrong directive proxy_ssl_protocols Enables the specified protocols for requests to a proxied HTTPS server. when you should be using the ssl_protocols Enables the specified protocols.


1

You can create all the Root and Intermediate CAs and issue certificates from them for your servers all day.. but the browser you use to connect to those servers is not going to trust those certificates until they're explicity told to do so. You have to either import the Root CA into the client/browers's trusted root store, or have the server certificate ...


1

The directory specified in CApath must have a special structure. From OpenSSL docs If CApath is not NULL, it points to a directory containing CA certificates in PEM format. The files each contain one CA certificate. The files are looked up by the CA subject name hash value, which must hence be available. If more than one CA certificate with the same name ...


1

openssl s_client -cert $file can provide only 'the' client cert (singular, one), not a chain; it can optionally provide the privatekey as well, if you don't specify -key, but still not any cert(s) other than the client cert. If you put any additional cert(s) in that file they are totally and completely ignored. But libssl uses certs from the truststore to ...


Only top voted, non community-wiki answers of a minimum length are eligible