I am a newbie developing an Android app. It implements a socket connection and has to bypass or allow all host for it to work with our self-signed certificate installed on a server.
I heard that google play store doesn't accept this kind of connection in the published app. Is it true? Or there is another way to do it?
Thank you.
and had to bypass or allow all host in order to work with our self-signed certificate installed on server
That was not a particularly good move, from the standpoint of security.
I heard that google play store doesnt accept this kind of connection in the published app
The Play Store has implemented a ban on apps that bypass SSL validity checking and blindly accept all incoming SSL certificates.
Or there is another way to do it ?
Android 7.0+ has support for self-signed certificates. I backported that code to work on Android 4.2+. There are other libraries that offer self-signed certificate support, such as this one. There have been articles written on using self-signed certificates.
Related
I purchased the domain name 'jimtough.org' directly from Amazon so I could use it with a Cloudfront distribution. Now I have a very simple vanity site at https://jimtough.org/ that uses the certificate. I also played around with AWS API Gateway and confirmed that I can use the same certificate to provide HTTPS secured URLs to work with API Gateway.
I am also running a Java/Spring Boot web application on an EC2 server. I have already associated a Route53 DNS name with the EC2 server that hosts my Spring Boot application, like this: http://instance-b.jimtough.org/. This works, but it is using unsecured HTTP. I get a bunch of warnings when I try to do basic authentication in the application, since it would be sending my username/password via an insecure connection. Fair enough.
So my next step is to enable HTTPS in Spring Security and force secure connections to the application. In order to do this, I first need to provide a certificate for the Java runtime on the EC2 host to use. I found examples of how to do so with a self-signed certificate:
https://mkyong.com/spring-boot/spring-boot-ssl-https-examples/
https://www.baeldung.com/spring-boot-https-self-signed-certificate
Unfortunately, using a self-signed certificate is not what I'm looking for. I want the user to be able to browse my static content vanity site first (https://jimtough.org/), and then follow a link to my web app and keep using the same site certificate (my AWS-issued cert) for my Spring web app.
QUESTION: How can I use my AWS-issued certificate with my Java-based web application?
Inside the AWS Certificate Manager (https://console.aws.amazon.com/acm/home?region=us-east-1#/), I don't see any way to 'export' or save my certificate. Am I missing something? Maybe Amazon doesn't want me to use this certificate outside of their own services?
Note that I did originally set up the certificate with the domain name as 'jimtough.org' and the Additional Names field set to '*.jimtough.org' so I can use the certificate on sub-domains as I'm trying to do here.
EDIT
The accepted answer from julien-b is correct. I did some more research and found that SSL certificates aren't cheap, and come in different flavors. The cheapest is the 'DV' (Domain Validation) type, which only verifies that the SSL certificate is controlled by someone who also controls the DNS record for the associated domain (such as 'mydomain.com'). There are much more thorough (and expensive) certificate types that can be issued, where the issuer has to do background checks on the owning organization. Those are meant for sites that handle e-commerce, financial transactions, etc. Not at all what I need.
There are also multiple types of multi-site certificates to choose from. The very cheapest single-domain certificates only cover your primary domain and the 'www' subdomain (mysite.com and www.mysite.com). If you want all the subdomains of your primary domain covered (app.mysite.com, ftp.mysite.com, etc), then you'll need a 'wildcard' certificate. Those are significantly more expensive. The more exotic certificate types can cover multiple different domains. These seem to be aimed at making certificate management easier for organizations that manage a lot of different domains and don't need a different certificate for each. Not what I need, so I didn't investigate further.
I decided to go with a 'single-domain with subdomain wildcard' certificate from Comodo (recently renamed to Sectigo?), who appears to be the most affordable certificate vendor right now.
REFERENCE: https://www.techradar.com/news/best-ssl-certificate-provider
It seems like a missed opportunity for Amazon that they don't get in on this game and issue their own SSL certificates for a fee. AWS already has all the infrastructure in place to do so, at least for the DV-level certificates.
You cannot export the private key of a publicly trusted ACM certificate. You can use ACM certificates with some managed services, but it doesn't work for all use cases.
https://docs.aws.amazon.com/acm/latest/userguide/export-private.html
AWS Certificate Manager is integrated with other AWS services, so you
can provision an SSL/TLS certificate and deploy it with your Elastic
Load Balancer, Amazon CloudFront distribution or API in Amazon API
Gateway. AWS Certificate Manager also works with AWS Elastic Beanstalk
and AWS CloudFormation for public email-validated certificates to help
you manage public certificates and use them with your applications in
the AWS Cloud.
https://aws.amazon.com/certificate-manager/features/?nc=sn&loc=2
Should you want to use a certificate on a service that is not integrated with ACM or even on-premise, you should get your certificate from another source.
As for the ACM Private CA, it is meant to be used within an organization thus not matching your use case.
https://docs.aws.amazon.com/acm-pca/latest/userguide/PcaWelcome.html
I've read a lot of articles regarding the import of a cert, but I am still unclear on a couple things.
When connecting to an SSL site from a Java application [in this case, a JBOSS web app], does the client cert need to be explicitly installed on the application server prior?
I can install a client cert manually, but there is an expiration date. So I'll need to manage the expiration dates of all client installed certs on our application server, and take an outage to update each one.
It feels like there should be a better way.
Shouldn't the application automatically accept a valid signed cert? [In this case, it is signed by VeriSign]
We are getting an exception currently when trying to access an https url from the application without explicitly installing the cert.
The API proxy library is swallowing the internal exception, so I dont know the details.
If the cert should be accepted automatically, then there may be a different issue here...
Can a signed certificate be used without importing explicitly?
Yes, it does not need to be installed prior to use. In fact, if you know in advance of what to expect, then you can include that information into the application. That has an added benefit of improving the application's security posture.
To avoid importing the certificate, use a custom X509TrustManager and override checkServerTrusted. In checkServerTrusted, ensure the server's public key is expected (i.e., pin the server's certificate or public key); or verify the server's certificate is valid (i.e., is within validity and forms a chain to your trusted root).
When connecting to an SSL site from a Java application [in this case, a JBOSS web app], does the client cert need to be explicitly installed on the application server prior?
In the case of client certificates, the server advertises the issuer whom it relies upon to issue client certificates. So the server will need to know the trust point for issuing client certifcates for authenticating clients.
In this case, it is signed by VeriSign
This could be really bad. In this case, you will trust all of your clients signed under the Verisign PKI, and all of Verisign's other clients signed under the Verisign PKI.
In this case, it would probably be better to avoid public CAs and run your own PKI (i.e., be your own CA). In this case, pick up a copy of Network Security with OpenSSL. The book will show you how to accomplish the customary tasks using both the openssl command and programmatically.
I saw that there were a few other Java and CAC posts on stackoverflow. I am a beginner with all of this stuff and I am still trying to a framework of what to do and where to go in my mind.
I am doing work for a big org that is using CACs with Windows 7 boxes to authenticate users who want to get into their PCs. They stick the CAC in their keyboard and type in a PIN.
My boss would like to alter our Java Webap such that it will not make the users authenticate if they have their CAC in their computer. If not, they will go through the traditional LDAP login.
We are using WebLogic 11g and Java 6.
From Googling around it seems like there are two approaches:
Implement an applet to read the user's CAC and send an SSL certificate to the webapp.
Implement "mutually SSL authentication" in the web server, which will cause the browser to send the SSL certificate on the CAC to the webapp
Do I have a correct appraisal of my options?
Which solution is easier?
Which will be less hassle, more robust in the long run?
I know next to nothing about SSL, which seems to be common in both solutions. I've found a few SSL tutorials that go on at length about abstract concepts. Can anyone recommend a good tutorial for what I want to do?
Thanks much in advance for any information or tips
Steve
Implement an applet to read the user's CAC and send an SSL certificate to the webapp.
Implement "mutually SSL authentication" in the web server, which will cause the browser to send the SSL certificate on the CAC to the webapp
You will want to do #2. You don't really want to have to mess with smart card hardware / software. Let the OS do all that work.
I've done this on IIS, but generically, to implement this, you will need to configure your web server to require client certificates and to trust the DoD CAs. You may need to configure your web server to advertise to clients which CAs it trusts. If the Win7 clients have a client cert that is signed by a CA you trust, the client will attempt to use it. If it's a smartcard certificate, Windows will automatically prompt the user for the pin; you don't have to worry about that. If the user types the correct pin, the cert will be sent to your web server which should then be able to validate the certificate with the CA. If it's a valid certificate, your software can then parse the fields in the certificate and use the values to help authenticate the user (ie whether, despite having a valid certificate, the user is actually allowed to login based on their name / email address/ etc). It's up to you how to handle it from there.
You will have a much easier time figuring this out and finding information if you forget that the users are using a smartcard or a CAC, and just start with the idea that you're going to use client certificates for authentication. Start by creating a self-signed CA test cert. Then create a server cert for your webserver and a client-certificate signed by your test CA. Add the test CA cert as trusted root cert on the client and the server. Then attempt to write a small test app that uses the client cert to authenticate to your webserver. Once you have that working, you can add the DoD CA and try to pull the info out of a CaC certificate.
good luck!
I need to do this thing:
communicate using ssl from android terminal to a server;
each android client has its own certificate (we can say mutual authentication);
the ssl certificate must not be in the application (each person install his certificate on his phone).
How can I do it?
Obviously point 1) alone is easy (I build a keystore/truststore as explained in stackoverflow). The problem is in point 3).
Thanks,
Mario
If you are targeting Android 4.0 (ICS), you can use the system key store via the KeyChain API. For other versions, users need save their keystore somewhere (on the SD card/external storage, etc.) and let your app know where to find it.
I want users to be able to install their own personal certificate into my Android application after installation from a website which generates the certificates, but when I use a WebClient or the Android Browser to surf to it, the Secure Storage pops up and installs it, which is unavailable by API until version 14 (Android 4.0), which my users do not have installed.
An example of such a site is http://www.comodo.com/home/email-security/free-email-certificate.php .
Here you can request a personal certificate, and after confirming, you get a link where you can download the certificate.
I want users to be able to download certificates from this website, and others, into my application.
Can anyone tell me which intent to handle to be able to get the certificate into my own application, or how to modify WebClient such that it allows me to decide what it should do with the file?
Thanks in advance,
Patrick
Since the Android keystore API is not public before ICS (4.0), you need to save the key and certificate to some file your app can access to be able to use them. If you require a standard password-protected Java keystore file and require password input for crypto operations, it would be reasonably secure.
You can import a key/certificate pair in pre-ICS versions using Settings->Location and security->'Install from SD card', but there is no public API to access those from your app, the can only be used by the built-in VPN client.