Re: Question: How to using cert files on Android platform?
On Wed, Mar 03, 2021 at 01:56:31AM +, Yang Rong wrote: > I am new to OpenSSL. I am working on a project using JNI+ OpenSSL on > an Android App. Can you briefly explain your motivation for using OpenSSL via JNI, rather than just use the native android TLS APIs, which then just use the Android trust store? > The OpenSSL is not able to use certs in the Android trust store. The Android trust store is likely more fine-grained than you'd naively expect. Not all the trusted certificates are necessarily trusted for the same purposes. If you just extract the certificates, without the associated trust settings, you may well end up undermining some of the expected security properties, because some restricted use certificates may then lose their associated restrictions. > Do we have a way to use the Android trust store in 2021? The simplest and generally most appropriate answer is: via the Android APIs, and without JNI into OpenSSL. If you have a compelling reason to use OpenSSL, you'll probably need to provision a dedicated trust store of known to be appropriate trust anchors. > The target API level of the Android App is 28. If OpenSSL is > still not able to use the Android default trust stores nowadays. I > would like to copy the certs from Ubuntu to the Android app. If it is appropriate to trust the same root CAs (something probably along the lines of the Mozilla cert bundle), then you could do that, but why is this necessary? > But I need to figure out which pem file is used to establish > connections. Now it seems that you're not well versed in OpenSSL, which strongly suggests that it is really best to stick to the provided APIs, and not roll your own security toolkit. > Is there a way any OpenSSL command line cmd is able to do > that? Almost certainly, but your question is rather oddly phrased and not completely clear. PEM files don't establish connections. Are you looking to capture the entire Ubuntu trust store, or just the specific trust-anchor that is *currently* the ultimate issuer of the server's certificate chain? Do you have good reason to believe that the server will continue to use the same root CAs indefinitely? ... If your reasons for not using the Android APIs are not absolutely compelling, your best bet is to use those, despite whatever non-critical disadvantages are driving you to consider OpenSSL instead. -- Viktor.
Question: How to using cert files on Android platform?
Hello, I am new to OpenSSL. I am working on a project using JNI+ OpenSSL on an Android App. My task is to create a client to access some web services. Currently, I am able to use the default trust store (/etc/ssl/certs) on Ubuntu18.04 to access the web services. But based on https://stackoverflow.com/questions/15375577/how-to-point-openssl-to-the-root-certificates-on-an-android-device The OpenSSL is not able to use certs in the Android trust store. That is an old thread. Do we have a way to use the Android trust store in 2021? The target API level of the Android App is 28. If OpenSSL is still not able to use the Android default trust stores nowadays. I would like to copy the certs from Ubuntu to the Android app. But I need to figure out which pem file is used to establish connections. Is there a way any OpenSSL command line cmd is able to do that? Thanks Rong r0nG Auckland, New Zealand
Re: Query on SSL Mutual Authentication on Server
On 2021-03-01 17:28, Viktor Dukhovni wrote:
On Mon, Mar 01, 2021 at 09:21:29PM +0530, Archana wrote:
I am new to SSL programming. On our SSL Server implementation, we are
trying to enforce Mutual Authentication. Is it Mandatory to provide a user
defined Callback using SSL_ctx_setverify()
No callback is required (callbacks are primarily useful for logging,
though they can also, with care, be used to make chain verification
more "permissive", but there be dragons). However, you must then
still call:
int mode = SSL_VERIFY_PEER
| SSL_VERIFY_FAIL_IF_NO_PEER_CERT
| SSL_VERIFY_CLIENT_ONCE;
SSL_CTX_set_verify(ctx, mode, NULL);
to set the verification mode to request (and enforce) the presence of a
client certificate. Depending on the client, you may also need to make
sure to provide a non-empty list of client CA hints that includes all
the trust-anchor CAs from which you'll accept client certificate chains.
(Clients using Java SSL APIs typically require that to be the case).
This can be done via:
const char *CAfile = "/your/CA/file";
STACK_OF(X509_NAME) *calist = SSL_load_client_CA_file(CAfile);
if (calist == NULL) {
/* log error loading client CA names */
}
SSL_CTX_set_client_CA_list(server_ctx, calist);
If yes, Is it expected to do the IP or hostname validation?
Neither, authorization of the client is up to you. OpenSSL will check
the dates, validity of the signatures, ... in the clients certificate
chain, but checking whether any of the subject names in the client
certificate are allowed to access your server is up to you.
There is no prior expectation that the client's certificate is
specifically related to its IP address or hostname.
You may in fact, depending on the structure of your code, be able to
configure the expected client name prior to the SSL handshake
with SSL_accept(3), but after accepting the client TCP connection.
To set the expected hostname(s), see the documentation of:
int SSL_set1_host(SSL *s, const char *hostname);
int SSL_add1_host(SSL *s, const char *hostname);
For IP addresses, there's a slightly lower-level interface:
X509_VERIFY_PARAM *SSL_CTX_get0_param(SSL_CTX *ctx);
int X509_VERIFY_PARAM_set1_ip(X509_VERIFY_PARAM *param,
const unsigned char *ip, size_t iplen);
int X509_VERIFY_PARAM_set1_ip_asc(X509_VERIFY_PARAM *param, const char
*ipasc);
or after the handshake completes, you can call one of:
int X509_check_host(X509 *, const char *name, size_t namelen,
unsigned int flags, char **peername);
int X509_check_email(X509 *, const char *address, size_t addresslen,
unsigned int flags);
int X509_check_ip(X509 *, const unsigned char *address, size_t
addresslen,
unsigned int flags);
int X509_check_ip_asc(X509 *, const char *address, unsigned int flags);
Just out of curiousity: What is the recommended way to check
the authenticated e-mail and/or DN of the client certificate,
given that those are the most common identities in such
certificates (except in server-to-server scenarios).
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
