IssueTracker

I have a similar problem with my enterprise CA.  Confusingly, the browser allows me
to import my CA's certificate (it starts CertificateInstaller and asks me for a
friendlyName for the cert), but near as I can tell doesn't do anything useful with
it.  It certainly doesn't consider the certificate "trusted" in any way.
(Installation of personal certificates from the CA is also broken, but I can't tell
from the error message whether that's because Android doesn't "trust" the CA or for
some other reason.)  This is really seriously broken and should have been considered
a showstopper before *any* Android product was ever released.

Running 2.0.1 on VZW Moto Droid here.

Sucess in importing a CA certificate for a WiFi network using the method described in
http://www.realmb.com/droidCert/ . The certificate must be in PEM format and
downloaded via http with a header "Content-Type: application/x-x509-ca-cert". You can
check the whole process (but in spanish) at
http://www.ua.es/es/internet/wirelessua/eduroam/peap/android_wpa_eap_peap_certificate

Android 1.6

While the Realmb.com method works for a WIFI certificate, the certificate is still
not being used to trust websites.  This is still a major problem.  (Verizon Droid
2.1)

Same as above with a HTC Desire 2.1-update1. The certificate seems to be imported via
Realmb.com but it is not used elsewhere (eg websites but also IMAP and SMTP servers
over SSL).

I can't export into a .p12, but can into a .pfx certificate. It would be helpful for
me if Android would accept the .pfx format as it is my understanding that it is the
same basic type of certificate. Thanks. I'm running 2.1 on an HTC Incredible.

[Comment deleted]

Same problem...
Need my personal CITRIX certificate to Citrix Receiver work...
When I try to Import, it keeps asking for a password forever...
Running Android 2.1(or trying to)on Motorola Milestone (Droid).
Guess it may be available on next 2.2..Please!!!

Same problem here using an HTC Hero (Sprint)...

I get a never-ending bad password loop as described above when trying to install
certs to our University Zimbra Collaboration Suite which uses SSL/TLS through
Exchange and/or IMAP/SMTP.  I cannot even access the web portal through the browser.  
The Realmb.com method seems to install the certificates, but the phone apparently
does not make use of them for anything other than wifi.

I work for the ITS department and this has been a major source of frustration as we
would like to be able to advise students, faculty, and staff of a variety of
smartphone option beyond iPhone and Windows Mobile.

I use HTC Desire. With default mail app I can receive mails(imap, port 143 TLS) but
sending does not work(with certificate signed by untrusted CA) - it even cant be
configured because connection is established and then reset. Conversion of root CA to
p12 and importing to the phone has no effect(altough imported successfully).
I use k-9 mail which works ok with self signed certs.

Even though it is a problem (at last for a lot of users) with both the vanilla
Android mail application (IMO allowing _all_ certificates is not a solution), the HTC
Sense mail application found in the HTC Desire actually _can_ use self signed
certificates. If the application is unable to retrieve the certificate during setup
(aka no internet connection), it will time out, and give you the option to proceed
without controlling the validity of the certificate. When you then later on enable
internet connection, the application will ask you to acceppt the certificate, and
will remember this choice.

To comment #10: for me, HDC Desire's mail app does *not* allow me to set up
connection to an SMTP server with certificate signed by a private CA. There is just
no way to move ahead from the SMTP server setup page. Admittedly, IMAP works with the
same certificate.

Once rooted, I was able to boot recovery image, mount /system -o rw, and add the CA
certificate to the system store, but this is hardly a good solution. There needs to
be an official way to add CA certificates system-wide.

#10. It does not work the way you described, at least for me. Even if this could work
like that, I do not think stopping the mail server(smtp tls), just to pass the setup,
is comfortable/possible for users.

#11, I confirm and agree. As I'm not going to root my system, there must be a way to
add CA to the system store.

And one more thing. I don't like such aproach when partially broken software is sold
and user has to report bugs and wait months for solution(@htc of cource)

@#12. I agree, stopping the mail server is not an option. I should maybe have told all the circumstances around what I did to make it work, as I may have been making a few assumptions.

When creating the account, I was connected to my company network, which is blocking IMAPS/SMTP/Submission-ports. When trying to connect, the wizard happily buzzes away, then hangs at "Verifying account information..." for a while, before prompting the "Warning // Cannot connect to the mail server to verify your account information. Your server is not responding.". This dialog provides OK/Continue options, and tapping continue will land you (or at least me) at the SMTP-prompt. Same goes for SMTP-setup.

There's no reason why this shouldn't be fixed though, as this "workaround" is flawed at best. Also.. The entire reason I find it worth mentioning these problems here (despite this, in essence, being an HTC-issue), is that I believe that a system wide solution for managing certificates through some key store would eliminate the problem in 3rd party mail applications, as well as those in the one bundled with Android. I can't really se any reason for not letting people add custom certificates, no matter how much it is possible to hack a way around it.

With the latest update for Htc desire(1.21.405.2) mail app asks to accept certificate. So it works now.

On my HTC Legend (build 1.31.405.4), it doesn't work either. HTC Legend's mail app does not allow me to set up the connection to an SMTP server with self-signed certificate. So I *do* agree with #11.

HTC EVO worked until midnight the first night with a self signed Exchange cert, then quit (perhaps some # hours or some other factor, but I was trying to read an email at 12:03am and it wasn't showing up on my phone). This is a HTC issue, but no notification for failure, it says successfully synced. Worse the only sign of a problem is in the settings / sync menus then going to Exchange ActiveSync (before going to the menu for Exchange it says successfully synced). Once I click the Exchange ActiveSync then Mail has O! (O being the circle which I can't type here). Sync Now is an option which simply says "Sync protocol error."

This is amazing that it asks to import the certificate, goes through all the steps, yet doesn't trust it afterwards - Perhaps it's putting it into the wrong section of it's store (?).

same problem with htc desire. can't send mail trough self signed tls mailserver. not fixed on htc desire (2.1-2)

Can anyone tell what Android does when you open a certificate in a browser with the correct HTTP headers set (like http://www.realmb.com/droidCert/ does)?

If we knew this, we could create an app to easily install certificates.

Same problem on Samsung Galaxy S

Hi... I've looked at the source code of android and apparently you can put a .crt in the root of your SD Card, to import your CA !! I've tested on my Nexus One and it worked => I have a popup saying :
"The package contains:
ne CA certificate"

Can somedy confirm on another platform ?

@20 I believe the problem is that, and I don't know how true this holds for the other models, with e.g the HTC Desire, the built in browser does not use this certificate store. It's only being used for authentication in wireless connections and VPN.

Again, not too sure about this, but I get the prompt to add the certificate, add it, and the browser (and email client) will still complain about it.

Agreed.  Other applications (citrix receiver for instance) that rely on SSL do not see that certificate store.

fyi, the source code is here (hard to find :)

http://android.git.kernel.org/?p=platform/packages/apps/CertInstaller.git;a=blob;f=src/com/android/certinstaller/CertFile.java;h=8e6379491fc342632e85396ccbc8ba75192d2133;hb=HEAD

I'll try to make an app to list, add, remove a CA certificate, based on that code.

to #23: yes, but I suspect that the problem may be at the receiving end of this intent

Intent intent = new Intent(this, CertInstaller.class);

the listener may be either absent of failing to store the new certificate data into the repository. I wonder if this may have something to do with the fact that (at least on HTC Desire) the "main" CA repository resides on read-only /system filesystem...

the library which deals stores the certificates seems to be android.security.KeyStore

http://android.git.kernel.org/?p=platform/frameworks/base.git;a=blob;f=keystore/java/android/security/SystemKeyStore.java;h=abdb0aed8ce5547a16b76363809bd1d2fcc0c522;hb=HEAD

Line 38 : it seems to be stored in directory misc/systemkeys

I don't have my google phone right now : do you have that directory on your HTC Desire ?

From reading the code of CertInstaller.java (that contains the executor of the intent), the whole thing is able to (1) import client certificate-with-key in pkcs#12 format, and (2) import signed client certificate (sans key) in .crt format *if* the private key is already present in the key store. As far as I can tell, it is incapable of importing CA certificates at all. Those who are in the know please correct me.

Anything new regarding this issue? I'm having the same problem with my Samsung Galaxy I9000.

@18 I believe that it adds it to the local credential store by calling ACTION_VIEW with the appropriate MIME type. I am thinking something like:

String mimeType = "application/x-x509-ca-cert";
Intent activityIntent = new Intent(Intent.ACTION_VIEW);
activityIntent.setDataAndType(pathToCert, mimeType);
activityIntent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
context.startActivity(activityIntent);

@28: Seems to be a good idea, but doesn't work yet. I tried

String mimeType = "application/x-x509-ca-cert";
Intent activityIntent = new Intent(Intent.ACTION_VIEW);
activityIntent.setDataAndType(Uri.fromFile(new File("/sdcard/test.der")), mimeType);
activityIntent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
startActivity(activityIntent);

and get:

android.content.ActivityNotFoundException: No Activity found to handle intent { act=android.intent.action-VIEW dat=file:///sdcart/test.der typ=application/x-x509-ca-cert flg=0x10000000 }

Any ideas?

@29 WAY off on my part. Looks like it is a bit more complicated.

I don't have a functional development environment at the moment due to an OS reinstall, but I believe that I have a bead on the correct method. It is out of android.security.CertTool. I am thinking something more like:

ByteArrayBuilder mDataBuilder = new ByteArrayBuilder(8192);
byte[] data = Base64.decodeBase64(PEM);
int length = data.length;
mDataBuilder.append(data, 0, length);
byte[] cert = new byte[mDataBuilder.getByteSize()];
int position = 0;
ByteArrayBuilder.Chunk c;
while (true)
{
        c = mDataBuilder.getFirstChunk();
        if (c == null) break;

        if (c.mLength != 0) {
                System.arraycopy(c.mArray, 0, cert, position, c.mLength);
                position += c.mLength;
        }
        mDataBuilder.releaseChunk(c);
}
CertTool.getInstance().addCertificate(cert, mContext);

The above is not mine... I just extracted what I feel pertinent from webkit's LoadListener.java and modified it slightly. Without a functional dev environment I am not sure if it will even run. I may work on this over the weekend and look into developing a tool to load and enumerate the CA certificates in the store...

I actually use a mail server with an official mobile ssl certificate and i keep getting an error that it is an invalid certificate when setting up ssmtp (smtp+ssl) in the mail application.
In the browser the certificate is correctly accepted (it is also used for the webmail).
I have contacted our certificate provider and based on the details, they say the mail application actually loads the wrong certificate. It loads the root certificate instead of our certificate!

The IMAP configuration is also configured to use SSL and it works fine so this does not seem to be a certificate issue, but a software issue retrieving the wrong certificate!

I refer to the comment above (31). It may be the behavior of the particular email client you use but if I install a root CA certificate into the phone, I should be able to use that CA on web sites signed by that CA. The web browser currently does not even do that.

Similar problem here (HTC Incredible v2.1 w/stock Sense mail app) Killing the netowrk socket on the mailserver during setup works fine for inbound IMAP over SSL/TLS, but I can not get outbound mail (submit/587 with TLS) to work using the same method.  Successfully imported CAcert via browser, but it seems either that browser and email do not use the same keyring or there is some other issue specific to SMTP/TLS.

Being the sysadmin in our enterprise environment, exposing clients to MITM attacks is just plainly unacceptable. We have clear instructions on how to install our company's root CA on most client platforms (thus making our users experience secure and seamless)... except for Android :-(
Installing custom root CA is a "MUST have"!

If Android is to be considered seriously for enterprise use, relatively simple tasks such as trusting a CA or certificate should be available.  Enterprise customers and IT departments will not use a device that cannot comply with the corporate IT policies including, Exchange ActiveSync Security policies (especially encryption), PKI, and certificates.

Please add the ability to add certificates to the trusted root CA store to the next minor release or at minimum to 3.0.

Also, could Google please provide a current list (and one that is updated regularly) of the trusted root certification authorities for each Android release?  If we enterprise customers are going to try to support Android and we don't have the ability to add our own CAs then we need to at minimum know what CAs are trusted so we can make an informed certificate purchase decision.

As an FYI for others, the free/low-cost StartCOM/StartSSL CA is not currently trusted as of Android 2.2 (Froyo).

If Android is to be considered seriously for enterprise use, relatively simple tasks such as trusting a CA or certificate should be available.  Enterprise customers and IT departments will not use a device that cannot comply with the corporate IT policies including, Exchange ActiveSync Security policies (especially encryption), PKI, and certificates.

Please add the ability to add certificates to the trusted root CA store to the next minor release or at minimum to 3.0.

Also, could Google please provide a current list (and one that is updated regularly) of the trusted root certification authorities for each Android release?  If we enterprise customers are going to try to support Android and we don't have the ability to add our own CAs then we need to at minimum know what CAs are trusted so we can make an informed certificate purchase decision.

As an FYI for others, the free/low-cost StartCOM/StartSSL CA is not currently trusted as of Android 2.2 (Froyo).

On HTC EVO with froyo 2.2
Stock web browser will not trust SSL certificate issued by Trustwave
CN:SecureTrust CA

Dolphin web browser will not trust, either.

Has anyone found a list of Android trusted certs? How do we know what company to to purchase a cert from (for browser use--not email)?

Update-----I just got this response from Trustwave:

*****
Hello,

Unfortunately, all of our products require that the Android OS update it's root certificate.

-Trustwave SSL Support
*****

This means that our SSL certificate is useless on all Android devices.

I created http://code.google.com/p/android/issues/detail?id=11108 for the request to add 'C=US, O=SecureTrust Corporation, CN=SecureTrust CA'.

I agree with others here that a list of root certificates install on Android is a must.  It's very difficult shopping for the right CA when you don't know what you really need to support your users' phones.  

After renewing my mail server's GeoTrust QuickSSL certificate today, it seems the GeoTrust Global CA root certificate and / or GeoTrust DV SSL CA intermediary certificate is not installed on Android 2.2.  As a result, the only way to get our Android 2.2 phones to synchronize now is to tell the phone to allow untrusted certificates connections (or whatever that checkbox says).  I still have to play around with manually installing a certificate on our Android phones to see if that will help, but this really should not be something that we need to worry about.  HTC Droid Incredible, Motorola Droid.  

All of our Windows Mobile 6.x phones work just fine after the certificate renewal.  The root and intermediary certificates have been tested and are installed correctly according to GeoTrust.  

Android - please give us a list of installed root certificates and let us install certificates more easily!

I think we can safely say that the ability to add a new CA is critical to many of us.  I for one could use some kind of overview of which apps actually use the system keyring and which use their own, separate certificate stores.  Specifically, it appears that the browser, native mail application, HTC mail application, and WiFi client are not using a unified store.

Again, there is a usable (but inconvenient to manage) IMAP workaround but as far as I am aware, there is no workaround for SMTP/Submit with TLS.

josslerbob, GeoTrust provides a "cross root" to deal with this problem. There was some discussion at the GeoTrust issue at

http://code.google.com/p/android/issues/detail?id=10985

which referenced

https://knowledge.geotrust.com/support/knowledge-base/index?page=content&id=AR1426&actp=search&viewlocale=en_US&searchid=1283360269668

josslerbob,
I also meant to mention that same issue has a list of the open source trees default list of CA certificates: http://code.google.com/p/android/issues/detail?id=10985 Note that manufacturers and carriers can certainly add or remove from this list.

stadler, can you comment on kalbershardt's "SMTP/Submit with TLS" issue?

kalbershardt, as far as I known, only the VPN client uses the installable certificate/key support. Specifically the default browser and email clients do not. there are separate issues for each of those apps. I've never looked at the WiFi cert support, but I believe there is an issue for that as well.

I don't have any knowledge of the HTC client. I do know other third party mail clients such as Nitrodesk Touchdown support customizable certificates, in that case of Exchange authentication.

To follow up what Brian said, we're up to 47 comments (48 now) covering a pretty wide range of topics.  I'm going to close this bug and encourage folks to refer to existing feature requests, against some more specific features, so we can all track these issues more effectively.

Some notes in particular.

1.  Client certificates for VPN are supported, and if you are seeing problems with this specific use case, please file a new bug with as many details as you can share - or find an existing bug to join.

2.  Client certificates for the browser are covered in existing bug reports such as 8196 or 9152

3.  Client certificates for the platform Email client (e.g. on Droid or Nexus One) are not supported.  If you need them, cc bug # 3620.

4.  Other email clients (e.g. TouchDown, K9Mail, HTC Sense) are not tracked here and bugs or feature requests should be addressed to the developers or manufacturers as appropriate.

5.  For any other issues, please be sure to check the issue database before creating a new issue.

Oh boy, oh boy!

You are declinining this bug on the grounds that there are existing bugs about *client* certificates support. This bug has *nothing* to do with client certificates whatsoever! It is (was?!) the "central" bug to deal with Android's inability to import *CA* certificates.

"For any other issues, please be sure to check the issue database before creating a new issue." - yes *this* was presicely the existing report for the particular problem of CA certificates. And you declined it! So what we are to do next?

I absolutely agree with egrosser here..

This is a general mish mash problem, and should be solved with a general mish mash solution.

Having a central certificate store without the possibility to alter what certificates are stored is nothing short of a bug. I'm not even going to list up all the possible scenarios where you would want to add or delete certificates, but not being able to do so is, IMHO, a huge shortcoming.

This is amazing! This bug is about controlling the trusted root Certification Authorities, not about client certificates. We need a simple way to at least add a CA to the store without rooting the phone. Even the iphone has that!

I am somewhat troubled about the apparent lack of coordination of architectural issues here.

a) As egcrosser and fabrice.rossi already pointed out, we are talking about a CA certificate store bug that is not directly related to clients certs.

b) It would make sense to have a centralized storage instance for certificates (think macosx keychains), with a generalized API that is used by applications. This would keep people from reinventing the wheel all day long (as we can currently see in the different mail clients, etc., that come with their own flavors of TLS/SSL support and so on).

c) From a security standpoint, it is MUCH easier to test, audit and validate SSL and TLS scenarios, when there is a single instance of cert store and a single standardized operational API (which ought to be simpler to operate and with less bilerplate code than OpenSSL, for example). This would lead to less headaches for the adoption of Android systems in bigger (industry) orgs.

d) The current situation encourages software authors to roll their own implementation. I see this as counterproductive in the long run. (cf. b)

e) The user and/or administrator has to have control how and which certificates are used for what, or the system will not likely be deployed in industrial settings. It is an old and very awkward attitude in the handset-market that the handsets are owned by the operator and not the users. This reflects the era of ma bell. In 2010 handsets have basically become ultraportable computer systems that also serve as phones. Therefor the configurability of the software-side has to be open and flexible, because the usage profile differs dramatically.

Please rethink your decision and solve this problem on the architectural level.

Another vote against closing this unresolved issue.

stadler@android.com closes the bug and points to a number of unrelated issues about client certificates as justification.

I don't get this. This issue has NOTHING TO DO with client certificates. There are other issues that deal with that.

This issue is about importing new Certificate Authorities which Android does not handle and should.

Can we get this reopened and stay focused on the issue?

One more vote to re-open this issue.

The initial subject of the issue was "Cannot import CA certificates" which still exists.  How can this issue be declined if major functionality of the OS (the ability to use Enterprise PKI CA servers other than those in the included bundle) is hindered by this defect/enhancement request?

We don't even have a reference as to which "public" CA's are supported/trusted so how can we in good conscious recommend an Android device for enterprise use?

I would think that Google has it's own internal PKI intrastructure that Android needs to support.  This defect alone would render an internal PKI infrastructure useless for Android handsets.

My company (only 4000 persons) just decided to avoid Android phones, because of this issue. What a pity!

Please reopen, our IT support company refuses to support Android for this exact reason. We are forced to use either Blackberry or IPhone, neither of which are liked by many of our employees.

please re-open this issue.

The initial subject of the issue was "Cannot import CA certificates" which still exists.  

We have students complaining about our services because they can't use them, and I can't even go buy a "supported" cert cause there is no reference as to which "public" CA's are supported/trusted!

This issue is about importing new Certificate Authorities which Android does not handle and should.

The eduroam (www.eduroam.org) project provides access to IT infrastructures at universities all over the world, having several millions of registered students.

None of them can use it with an Android phone because of this issue.

Although I strongly second the request to have CA certificates for Android and Android Apps like Browser/Mail importable, I have to state to #58 that eduroam works for me with Android.

Hello users & reporters:

Thanks everyone for your feedback on this and the other issues.

My comments in #48 were intended to help folks with unrelated issues find the bugs that correspond to what they're dealing with.  It was an oversight that I didn't mention the original issue - importing CA certificates - in that comment.  

I apologize for the implication that importing & managing CA certificates is not an important feature request.  We believe that it will be a great addition to the Android platform.

Still, as I noted before, this issue report has become too gummed up with unrelated information to be useful - it's very difficult to track issues when the comments become so intertwined and filled with unrelated information, and it is confusing for users who are searching for existing reports.  I am keeping this issue closed, and I have opened a new issue here:  http://code.google.com/p/android/issues/detail?id=11231   For those of you looking for this feature, I encourage you to visit that page and click "star".

Thanks
Andy Stadler

I would just like to point out, that installing intermediate certificates and cross-signing certificates is not an client issue. These should be provided by the webserver using the certificate.

As Geotrust states in the KB referenced earlier: "...you may need to install the GeoTrust Cross Root CA to enable trust for your SSL certificate."
In other words: YOU need to install the cross/intermediate certificates needed in order to make YOUR SSL certificate work on YOUR server.

Some CA's even have multiple intermediate certificates, depending on the use. I.E. GlobalSign has one intermediate for Exchange/UC/OCS and another for general use (SGC-feature is disabled for the Exchange/UC version). Basically enabling the the admin to switch SGC on and off as needed.

Somewhat off-topic (sorry), but maybe useful to you anyway:
We are currently working on an online SSL tester that will help SSL owners to find certificate errors such as missing intermediate certificates.
http://www.ssltest.net/
We collect the testing information in order to make the testing better and more helpful (IT WILL CONTINIUE TO BE A FREE SERVICE), but this information is not shared in any way with anyone.
Also, this service allows you to subscribe to alerts - sending an notification before your certificate expires.
If you have issues with any client devices or browsers using your cert or just want to test, please feel free to use this testing tool.

Best /Jon

Sorry Jon, but this is 100% useless if your _Root_ CA is not trusted by the android device. And this is the case for every company running their own CA so Android cannot know and trust the root. And this is the case when you have a 100% valid cheap certificate, because those root CA are not in Androids certificate store.

You may build certificate chains as long as you like, but if you cannot connect it to a cert that your device trusts, your plain doomed. Then you have to import the last link into the cert store, theres no way around that.

Ah, but of course. We do not disagree.
No Root - no trust.

I was just pointing out that is is not the task of the client to bring alle the intermediate/cross certificates into the validation process. That is the task of the server.

Earlier, there was made an reference to cross certificates. The point I was trying to make was simply that we should not need to worry about intermediate/cross certificates when designing the Android certframework, as those should always be provided by the server.

Obviously, the client must be able to correctly process intermediate certificates recieved by the server and build the trustpath, but it does not _NEED_ to be able to hold intermediate certificates for server validation.
Actually, IMO the local intermediate certificate store should only be put to use when using client certificates, as the serveradmin may switch intermediate depending on the situation.

Just to make an example:
Windows/IE is able to find missing intermediate certificates using windows update.
Let's say that you use a GlobalSign domain or organisation validated certificate for your Exchange 2007/2010.
- If you DO NOT install the correct intermediate on the server, the client will use the wrong intermediate from windows update, and your Outlook client will fail connecting.
- If you DO install the correct intermediate, the server will provide the intermediate cert along with the server cert and your Outlook client will connect successfully.

That being said, If Android is to have any future as a business device, it _MUST_ _HAVE_ one, single point of certificate management.
No helpdesk or admin will ever accept to manage 2-3-4 different application specific certificate stores in a single device. They will simply banish the OS from the network (as they have already started to do).

If Android is to have a bright future, It should have some easy to use tools for administrators to deploy Enterprise/internal Root certificates AND enrollment of client certificates. Such tools could however quickly turn Android into the new baby of the IT departments all over the world (at least, if they get a hold on some of the other issues as well).

Allowing users to add new root CA certificates to the OS trust list is a must for the Android to occupy enterprise segment. And there should be an easy option for enterprise administrators to manage such certificates on devices, like CPF == certificate provisioning files we can create on Windows Mobile.

Yet another vote to reopen tis thread and get this fixed ASAP!  My company is also using the Geotrust cert for email.  Apparently they installed it in mid September because that is when my Work email stopped syncing with cert errors in the log.  Guess what?  They will not install anything just to support me.  We are a huge company and not a lot of android users.

Because there is no central certificate manager, I cannot use my work email anymore.  This has sucessfully turned my Android in to overpriced paperweight.

Between this and the lack of NTLM support, I have no choice but to move to a Windows Phone as soon as I can.  

"Driod Does(n't)"  :(

@rogerstigers While I see this stupid problem as a major one as well, any alternative that costs more than 20 US Dollar is just an overreaction.

If you are willing to spend money then you should try Touchdown by Nitrodesk which will work with any technically correct certificate and you can have a free trial to be sure it fits your needs and works with your server. It does for me.

Keep this open. While I can use email without a problem I cannot connect to the company wireless on the phone which limits some of my functionality when not at my desk. I have a few apps that will only work when connected to the company LAN and I can't use them because I cannot import a .cer certificate to use with wireless

@daniel.eckl  Thanks.  I am reviewing the trial now.  I was not aware that this was out there.

rogerstigers and TealTurboSer, please see for future updates on this issue: http://code.google.com/p/android/issues/detail?id=11231

Private detective(BachTin)

http://thamtubachtin.com

Is there another bug we should be following for CA certificate support?  I saw lots of pointers to client certificate support bugs, but I'm not interested in client certs, just CA certs.

freemanr...@gmail.com,

The issue mentioned in comment 69 covers both CA and client certificates:
Issue 36921330: Provide support for managing CA and client certificates
http://code.google.com/p/android/issues/detail?id=11231

More than a year with a bug that could be solved if you would just allow to import a wpa_supplicant file or choose manually the certificate.

There's been enough android for me, too much missfunctions and bugs not solved for too much time :(

I'm in the same boat as everyone else. My company has chosen Android as the wireless platform they want to go with, but a lack of support for being able to import our own CA cert as a "trusted" cert is a show-stopper. Apple has done an excellent job incorporating this ability into the iPad... so????  Is Google NOT interested in securing a piece of the enterprise market share?  Really??

I observed an issue on HTC Desire and a newer HTC Sensation (2.3.3) where it was not possible to configure outgoing SMTP due to untrusted certificate in the chain. Unfortunatelly openssl s_client didn't gave me a hint, it looked all ok! The solution was to check the order of certificates they are submitted from server. In case of Startcom it has to be:

server cert
intermediate ca cert
root ca cert

Intermediate and root swapped causes the chain to be rejected by the device.
In one case I have had some other certs attached to the chain. This is being rejected.

In my case it was my mistake, however HTC Mail was really fussy.  

I hope this helps you some way.
Regards Jarosalw at silpion de

Jarosalw at silpion de,

Could you explain what you mean by submitted from the server? Do you mean the order they were installed on the mail server in question?

[Comment deleted]

People following this bug might be interested in:
https://code.google.com/p/cyanogenmod/issues/detail?id=4260

Cyanogenmod obviously shares the same code base.  They are looking to deploy a CA-management solution, and there is a 3rd-party application (that requires root) which is capable of doing this.

I would think that merging this code into AOSP settings application shouldn't be too difficult.  Then companies would be able to add CAs to the list at their discretion.

Currently I have use my own certificates store, because Android is not supported
usable certificate store, that can be managed by user.

;-(

My (UK) uni has the same problem. I have been told to install GlobalSign CA certificate on my Samsung Galaxy S2, but nothing happens when I try to do so. I have tried importing the certificate from my PC and it does then appear on my S2, but I am then told that there is no option for opening it. I am not an IT tecky and will be well out of my depth going into any sort of coding. Looks like I'll just have to keep lugging my laptop to uni - that has had no problem accessing the uni wifi.

[Comment deleted]

Sorry, I didn't know about this issue until someone made me aware of it tonight. I didn't look through all 80 comments, but this ability to add CA certificates was added in Android 4.0 Ice Cream Sandwich. Client certificate support was also added for Browser and Exchange authentication since I see some mentions of that. See http://code.google.com/p/android/issues/detail?id=11231

Having same issue in Nexus 6p device with 6.0.1 , Not able to import .pfx file with right password. it is saying that password is incorrect but it is not ..

gaurav.bhuva, please file a new bug.