COMODO SSL Certificate on apache CentOS - android

I have deployed COMODO SSL on Apached CentOS but does not work on Android Older Versions.
I think I am missing something. I configured as below.
SSLCertificateFile /etc/pki/tls/certs/my_domain_com.crt
SSLCertificateKeyFile /etc/pki/tls/private/my_domain_com.key
SSLCertificateChainFile /etc/pki/tls/certs/COMODORSADomainValidationSecureServerCA.crt
#SSLCACertificateFile /etc/pki/tls/certs/ca-bundle.crt
I received following files in a ZIP
AddTrustExternalCARoot.crt
my_domain_com.crt
COMODORSAAddTrustCA.crt
COMODORSADomainValidationSecureServerCA.crt
Please correct me if I am wrong.

I have resolved the issue got help from this URL.
[http://billpatrianakos.me/blog/2014/04/04/installing-comodo-positive-ssl-certs-on-apache-and-openssl/][1]

Related

Cannot establish TLS with client

I have configured android APP to bypass certificate pinning using some modification of app and installed mitm certificate as system and user in android
After running mitmproxy and mitmdump i got below error
however i tried all possible way to solve issue but only in one app i am facing this error
Certificate verification error for www.kjljjlk.com.mx:
("hostname 'www.hjkhjk.com.mx' doesn't match either
of 'a248.e.jhkhkdsfsf.net', '*.dsfsfds-sdfsdfdsf.net',
'*.sdffdsfsdf.net', '*.dsfsdfdsf-sdfsfsf.net',
'*.dfsfsdsdf.net'",)
<< Cannot establish TLS with client (sni: xyxyxyxy.com): TlsException("SSL handshake error: Error([('SSL routines', 'tls_process_client_hello', 'parse tlsext')])")
I also try to run with burpsuite, but i get unknown_ca error
After all i tried to open site in firefox, and i get warning of potential risk
xyxyxyx.com uses an invalid security certificate. The certificate is
not trusted because it is self-signed. Error code:
MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT
so i click on accept risk and continue, then it open
but somehow in android app it is not accessing site
any help pls
Thank you
======
> Mitmproxy: 5.0.0 binary Python: 3.7.5 OpenSSL: OpenSSL 1.1.0j 20
> Nov 2018 Platform:
> Linux-5.3.0-7625-generic-x86_64-with-debian-buster-sid
As a general rule, you can disable certificate checking with the ssl_insecure option.
What TLS versions are supported by the server? It might be that the server is TLS 1.3 only, which mitmproxy doesn't support at the moment (https://github.com/mitmproxy/mitmproxy/pull/3692).
#MaximilianHils
from mitmproxy import options
from mitmproxy import proxy
from mitmproxy.tools import dump
myaddon = Myaddon()
prot = sys.argv[1]
opts = options.Options(listen_port=int(prot), ssl_insecure=True, http2=False)
pconf = proxy.config.ProxyConfig(opts)
m = dump.DumpMaster(opts)
m.server = proxy.server.ProxyServer(pconf)
m.addons.add(myaddon)

Intermittent and continuous SSLHandshakeException while connecting to android.googleapis.com/gcm/

We are facing some issues in connecting to Google’s GCM API (https://android.googleapis.com/gcm/send ) for Android push notifications from our server (SSLHandshakeException).
From 28th February to 8th March 2018 the issue was intermittent(push sent sometimes, SSL handshake error otherwise). From 9th March 2018 the issue is continuous.
Please see the logs below. Would like to know if there was any changes to the issued certificates.
com.sun.jersey.api.client.ClientHandlerException: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
at com.sun.jersey.client.urlconnection.URLConnectionClientHandler.handle(URLConnectionClientHandler.java:151)
I do not fully understand the details, but when I update our push provider/server "External Services Certs" and add the cert below.. my push started working again. So even though the Equifax cert that I originally installed 2 years ago was working until a few weeks ago, something changed on the GCM server and that cert was no longer valid. It has an expiration date of Aug 2018, which is near, but should not expire till that date.
I did notice that the new cert is SHA256 and the original is SHA1, so maybe this is a required security upgrade. It kind of screws me since my push content providers are distributed, not in a single location where it is easy to update the cert :(
The cert that fixed my issue is:
-----BEGIN CERTIFICATE-----
MIIEXDCCA0SgAwIBAgINAeOpMBz8cgY4P5pTHTANBgkqhkiG9w0BAQsFADBMMSAw
HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMjETMBEGA1UEChMKR2xvYmFs
U2lnbjETMBEGA1UEAxMKR2xvYmFsU2lnbjAeFw0xNzA2MTUwMDAwNDJaFw0yMTEy
MTUwMDAwNDJaMFQxCzAJBgNVBAYTAlVTMR4wHAYDVQQKExVHb29nbGUgVHJ1c3Qg
U2VydmljZXMxJTAjBgNVBAMTHEdvb2dsZSBJbnRlcm5ldCBBdXRob3JpdHkgRzMw
ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDKUkvqHv/OJGuo2nIYaNVW
XQ5IWi01CXZaz6TIHLGp/lOJ+600/4hbn7vn6AAB3DVzdQOts7G5pH0rJnnOFUAK
71G4nzKMfHCGUksW/mona+Y2emJQ2N+aicwJKetPKRSIgAuPOB6Aahh8Hb2XO3h9
RUk2T0HNouB2VzxoMXlkyW7XUR5mw6JkLHnA52XDVoRTWkNty5oCINLvGmnRsJ1z
ouAqYGVQMc/7sy+/EYhALrVJEA8KbtyX+r8snwU5C1hUrwaW6MWOARa8qBpNQcWT
kaIeoYvy/sGIJEmjR0vFEwHdp1cSaWIr6/4g72n7OqXwfinu7ZYW97EfoOSQJeAz
AgMBAAGjggEzMIIBLzAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0lBBYwFAYIKwYBBQUH
AwEGCCsGAQUFBwMCMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFHfCuFCa
Z3Z2sS3ChtCDoH6mfrpLMB8GA1UdIwQYMBaAFJviB1dnHB7AagbeWbSaLd/cGYYu
MDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AucGtpLmdv
b2cvZ3NyMjAyBgNVHR8EKzApMCegJaAjhiFodHRwOi8vY3JsLnBraS5nb29nL2dz
cjIvZ3NyMi5jcmwwPwYDVR0gBDgwNjA0BgZngQwBAgIwKjAoBggrBgEFBQcCARYc
aHR0cHM6Ly9wa2kuZ29vZy9yZXBvc2l0b3J5LzANBgkqhkiG9w0BAQsFAAOCAQEA
HLeJluRT7bvs26gyAZ8so81trUISd7O45skDUmAge1cnxhG1P2cNmSxbWsoiCt2e
ux9LSD+PAj2LIYRFHW31/6xoic1k4tbWXkDCjir37xTTNqRAMPUyFRWSdvt+nlPq
wnb8Oa2I/maSJukcxDjNSfpDh/Bd1lZNgdd/8cLdsE3+wypufJ9uXO1iQpnh9zbu
FIwsIONGl1p3A8CgxkqI/UAih3JaGOqcpcdaCIzkBaR9uYQ1X4k2Vg5APRLouzVy
7a8IVk6wuy6pm+T7HT4LY8ibS5FEZlfAFLSW8NwsVz9SBK2Vqn1N0PIMn5xA6NZV
c7o835DLAFshEWfC7TIe3g==
-----END CERTIFICATE-----
I obtained it by running this openssl cmd and it is the second one in the chain. That CAfile parm is robably not needed, since I did not have that file and there was a complaint, but the required cert chain was still displayed.
openssl s_client -connect gcm-http.googleapis.com:443/gcm/send -debug -showcerts -CAfile entrust_2048_ca.cer
The issue was due to GeoTrust to GoogleTrust migration of the SSL certificates for googleapis.com. Issue got fixed when we imported new certificate from the URL: https://android.googleapis.com and added to our server's trust store.
Kari - that is what I figured. Thanks for replying.. but the URL you list gives 404.. can you double check and update if you have the correct URL.
I am seeing the same issue and the same SSL error. Any more discussion on this?

Volley library and HTTPS requests

I tried to look for some answers for me here, but I just fail to find anything that solves my problem.
In project I am working on we are going to change our domain. Change is bit tricky - we have to also change connection from HTTP to HTTPS. I've received .crt key (let's say, example.tech.crt - will change all of company name to "example"). After few hours of constant failures I decided to write here.
First of all, I tried using this tutorial http://ogrelab.ikratko.com/using-android-volley-with-self-signed-certificate/ - and it didn't work (I don't even mean that I had to use deprecated Apache libs because of API23). In case this is needed, this is how I created BKS file:
keytool -importcert -v -trustcacerts -file "example.tech.crt" -alias example_tech
-keystore "example_tech.bks" -provider org.bouncycastle.jce.provider.BouncyCastleProvider
-providerpath "bcprov-jdk16-146.jar" -storetype BKS
Then, I tried this approach Does Android Volley support SSL? - the one from best answer (with ignoring domain name check). I still tried to use BKS file - I've got some exceptions about casting errors, so I changed line:
CertificateFactory cf = CertificateFactory.getInstance("X.509");
to
CertificateFactory cf = CertificateFactory.getInstance("X.509", "BC");
as suggested somewhere - error still persisted. I tried to use .crt file instead of BKS - I still fail.
Every single time I get same error:
javax.net.ssl.SSLHandshakeException: javax.net.ssl.SSLProtocolException:
SSL handshake aborted: ssl=0x650f83a0: Failure in SSL library, usually a protocol error
error:14077102:SSL routines:SSL23_GET_SERVER_HELLO:unsupported protocol
(external/openssl/ssl/s23_clnt.c:714 0x5fda0d74:0x00000000)
I tried to do pretty much same requests using Postman and they work on same address without any problem, so this is not server problem. I tried to use various domains - example.tech, www.example.tech, example.tech:80 and so on (always with https of course).
Below is example curl-like request (of course censored):
curl request: curl -X "POST"
-D "grant_type=password&password=[passwordHere]&username=[emailHere]&"
-H 'Authorization: Basic [tokenHere]
"https://example.tech/oauth/token"
I fail to see what's wrong with my code and I'd be really happy to see what I am doing wrong in here. If there's any more code needed, feel free to ask for it (but 99% of it is like in second link, only with really small changes).
Consider this topic as example of poor comunication. After hours of trying to make this work we made to work:
we are NOT using selfsigned certificates, so adding key to application is terrible idea (since they change each 3 months)
unsupported protocol exception came from older Android APIs (<20 or <21), which are supported in this application. From I do understand (considering my poor knowledge about SSL connections) our site uses TLS, but older Android systems (pre-Lollipop I guess) have this turned off by default. Proper way of fixing this was creating custom TLSSocketFactory and using it in HurlStack used to initialize RequestQueue. After that exception disappeared.

DTLS Handshake Failure In Android Device

I am trying to implement DTLS in my Android client using openssl/bio.h library.
The same does not cause any errors in iOS, while in Android..the DTLS handshake failure gives the following error
ssl3_write_pending:BIO_NOT_SET
I do not understand that error, has anyone tried this before or faced this issue? Did not find much help through google
I got the DTLS Handshake working after changing my DTLS code ,which was earlier using OpenSSL TO BoringSSL.I changed all the functions signature from that of OpenSSL to BoringSSL.

Local HTTPS server on Android - using a dh file

I use OpenSSL to establish a secured connection with my local HTTPS server. The server is really simple as I basically used the Boost Asio example but only improved a bit.
The solution works on Win7 64b using OpenSSL-Win32 and the certificates which comes with installer downloaded here.
I have ported the solution on Android. The Android OpenSSL port is from here.
Everything works fine until the use_tmp_dh_file method is called:
_context.use_tmp_dh_file("/sdcard/Download/PEM/dh512.pem");
It always ends up with the Fatal signal 11 (SIGSEGV) at 0x00000014 (code=1) error.
I use certificates server.pem and dh512.pem from the /apps folder of Android OpenSSL port.
Does anybody have an idea what is wrong?
EDIT:
Using a dh file is not mandatory, it works without it, but I am only a one step further because now it fails when starting handshake:
boost::system::error_code error;
socket.handshake(boost::asio::ssl::stream_base::server, error);
Where socket is instance of:
typedef boost::asio::ssl::stream<boost::asio::ip::tcp::socket> sslSocket;
It ends up with the same error as above. It seems to be an Android OpenSSL-Boost ASIO issue.
The answer on this particular question is short and simple, but it was quite hard to find it. The native library implementing my HTTPS server was interfering with the other native library using OpenSSL as well.

Categories

Resources