I am seeing an odd issue with two of our externally facing systems where access over the web on HTTPS works, and uses the correct COMODO certificates, but internally it is using self-signed certificates.
The command being used to test this is:
openssl s_client -showcerts -connect wiki.domain.com:443
Externally, this returns:
Server certificate
subject=/OU=Domain Control Validated/OU=EssentialSSL Wildcard/CN=*.domain.com
issuer=/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA
Internally (from the local subnet) I see:
Server certificate
subject=/C=US/ST=Somewhere/L=Somecity/O=CompanyName/OU=Organizational Unit Name (eg, section)/CN=Common Name (eg, YOUR name)/emailAddress=Email Address
issuer=/C=US/ST=Somewhere/L=Somecity/O=CompanyName/OU=Organizational Unit Name (eg, section)/CN=Common Name (eg, YOUR name)/emailAddress=Email Address
Any idea why this would be happening please? I can't figure out what's going on here.
Please ask if you need further details, am happy to provide. Thank you.
Related
I have basic knowledge of SSL and can configure web site https certificate.
I used to believe
A 'secure' https website much have a matching(at least a wildcard
matching) certificate domain name
until today.
Take google.com as example:
By Chrome certificate viewer:
By openssl
openssl s_client -connect google.com
Got same result:
... depth=0 CN = *.google.com ...
This is just woking as expected for me.
But I just found(which was mistake when expecting cn.bing.com actually) a website bing.cn,
By Chrome certificate viewer:
By openssl
openssl s_client -connect bing.cn
Got different result:
... depth=0 CN = *.wordpress.com ...
And this is beyond my knowledge. Could you explain
Why can the domain name be different with certificate but still is secure?
Why does gui version(tls.automattic.com) and command version(*.wordpress.com) show different certificate domains?
Subject field is obsoleted by all modern browsers and they look for authorized names in Subject Alternative Name certificate extension:
and bing.cn is authorized by this certificate. In fact, this certificate is allowed to represent any name listed in this extension.
This question already has answers here:
SSL working in chrome but sometimes in Firefox and not on IOS, Android or Blackberry
(2 answers)
Closed 1 year ago.
I've put together a Linux (Centos 7) server to serve eye-n-sky.net.
Serving content from that site to browsers on Win10 and Linux systems works beautifully. However, when I use openssl to access the site,
openssl s_client -connect eye-n-sky.net:443
the site certificate is rejected,
Verify return code: 21 (unable to verify the first certificate)
I've concluded that the way a browser verifies the certificate is different from what openssl does. Am I on the right track?
I've tested this on three different openssl instances (Debian, Centos, FreeBSD) and have consistent results.
Openssl as a client to other sites, e.g. www.godaddy.com, microsoft.com, work fine, being able to verify the certificate against the installed CA chain.
Believing that I was missing a CA cert, I used the -CAfile option to specify the possibly missing cert, to no effect.
What am I missing? I'm guessing that openssl has a stricter verification discipline, but I don't know where that gets configured.
Thanks,
Andy
Summary: yes, eye-n-sky was providing only it's cert when it needed to include the intermediate and root certs.
However, it took me forever to figure out that my Apache version did not support including the chain in the server cert file. Instead, I had to provide the chain file separately in an SSLCertificateChainFile directive.
OpenSSL's command-line s_client utility has nothing built in to validate the server's certificate. Browsers have a built-in list of trusted certificates to verify the server certificate against.
You have to supply the trusted certificates using options such as -CAfile file or -CApath directory. Per the OpenSSL 1.1.1 s_client man page:
-CApath directory
The directory to use for server certificate verification. This
directory must be in "hash format", see verify(1) for more
information. These are also used when building the client certificate
chain.
-CAfile file
A file containing trusted certificates to use during server
authentication and to use when attempting to build the client
certificate chain.
Note the use of words such as "certificate chain". If you go to godaddy.com you'll see that the server's cert is for *.godaddy.com, but it was signed by Go Daddy Secure Certificate Authority - G2, and that intermediate certificate was signed by Go Daddy Root Certificate Authority - G2 - a different certificate. There's a total of three certificates in that chain.
Verify return code 21 is "no signatures could be verified because the chain contains only one certificate and it is not self signed", so if your CA file only had the certificate from Go Daddy Root Certificate Authority - G2 and not the one from Go Daddy Secure Certificate Authority - G2, OpenSSL would see from the server's cert itself that it was signed by Go Daddy Secure Certificate Authority - G2 and could go no further - it doesn't have that cert to see who signed it.
I have a scenario where I need to connect to HTTPS site from my application (glassfish server or apache server). Let me illustrate via some example.
For Eg. I need to connect to https://stackoverflow.com from my application. Stackoverflow has chaining as below
If I try to validate from the client with all the 3 certificate( endsite cert,intermediate,cert and root cert) all works well.
The Question is, which is the right way of providing certificates from the client. If I just provide the *.stackexchange.com certificate from the client like below it works( So should I use enduser cert or root cert)
openssl s_client -CAfile stackexchangecom.crt -connect stackoverflow.com:443
So If understanding is correct then the webserver at stackoverflow.com has bundled the enduser certificate with Intermediate certificate and with the Root CA hence I get the valid connection.
Note : I am aware of the way SSL certificates work and also the chaining. I just want to know the best or the pragmatic practice for providing certificates for accessing the HTTPS
According to https://wiki.jasig.org/display/CASUM/X.509+Certificates,
After the Server sends the certificate that identifies itself, it then can then send a list of names of Certificate Authorities from which it is willing to accept certificates.
I am wondering how to determine what this list is, and how to modify it.
The reason I am asking is that I am getting an infinite redirect between my server and my client after successful validation (i.e., the ticket stage), and I think it has to do with the CAS server not recognizing the CAS client's certificate (the client's certificate is self-signed).
If you want to see what this list is, you can use OpenSSL:
echo "" | openssl s_client -connect your.server:port
This will show various messages regarding the handshake, including the certificates and the list of CAs in the CertificateRequest message.
Ultimately, it's determined by the active X509TrustManager's getAcceptedIssuers() method. By default, this will be the list of Subject DNs of all your trust anchors (that is, the Subject DNs of all the certificates in your trust store).
Your client certificate will have to be verified by the server. This is normally done during the handshake by the trust manager, which (unless tweaked) will build a chain to a known CA (or at least known cert if it's the user cert itself) in the trust store.
Adding your self-signed certificate to your trust store should be sufficient. It doesn't have to be the cacerts file bundled with the JVM, you could make a copy of it and use the trust store settings of Apache Tomcat's connector to set it up.
I have a server with an SSL certificate and clients with SSL cetificates, all are signed by the same CA, and the CA is trusted on the server and clients as a root authority.
However none of the clients I have tried (iphone, chrome, explorer) will send the client certificate when the server requests it, even though they all verify the server certificate fine. They all claim not to have the certificate.
When I look at the client certificate in the certificate/profile/store they all claim it is verified and legit, and all the certificates verify fine using openssl etc.
Does an SSL client certificate need a specific name or other details so that client browsers will know when to use it? Kinda of like how a server certificate has to specify the exact domain as the name on the certificate?
The server is an apache2.2 server, but I don't think its a problem on the servers end.
Client certificates must have appropriate Key Usage and Extended Key Usage extensions set. What is "appropriate" in your case, I don't know for sure but the number of variants in Key Usage is small and you can check various values yourself.
You surely haven't forgot about the private key which should be accessible on the client side, have you?
There's a summary of the key usage and extended key usage extensions to use in this document:
http://www.mozilla.org/projects/security/pki/nss/tech-notes/tn3.html
(Although it is for NSS, it should apply to other products.)
You could also check whether the list of accepted CAs sent by the server is configured properly. This can be seen using openssl s_client -connect the.host.name:443, for example.