I maintain a x509 CA chain that signs certificates for a Seafile server in a local domain. The server sends the whole chain, in concatenated PEM format. The chain looks like this:
root ca
└── web services
└── seafile
I have installed root ca in all devices that need access to the internal services. Including the one that is complaining about seafile being invalid.
As you can see, hashes match, and chrome recognizes the server certificate as valid with no problem. The certificate has subjectAltName and subject:CN set to the domain used by seadroid to access the server. For the time being I’ll just tell people to accept the prompt only if the hashes match (which defies the whole purpose of using a PKI). I hope this gets resolved, thanks for reading.
Recent versions of Android (since v7 / nougat) do not trust user installed certificates. Switching over to lets encrypt solves the issue and also makes it easier for your users to use the service (not root required), At least I do not see any disadvantages.
Trusted root CAs can be added on Android without the need to have root permissions, it’s nothing rare, it is a feature widely used in the enterprise environment, as it allows firewalls to detect sensitive information leaks on encrypted channels. Let’sEncrypt certificates work fine in the public domain, but you can’t use it on local ones (it’s a policy that applies to all certification authorities).
I can’t believe that Seafile, that specifically markets a version of their cloud software as Community Edition does not allow Self-Maintained Root CAs as part of the Trust Chain. This completely eliminates the possibility of using encrypted channels on a local domain, a bad move in my opinion.
In the preferences of the seafile App, you can enable to trust not trusted certs, then it will work. But in my opinion, it’s much easier to use Let’s encrypt than use a self-singed one.
Yes, but if you’re letting untrusted certs through you might as well not even use HTTPS and maintain a PKI, and just expose all traffic using HTTP.
Again, Let’sEncrypt won’t certify local domains, like any other certificate issuer.
Well, yes, but that’s still a public domain.
That’s the main purpose, but it’s stupid and confusing, you might as well don’t even have a user certificate store if you’re just going to ignore it by default. There are already measures in place to block malicious user certs from being installed (having a lockscreen set on the phone and asking the user to authenticate each time one needs to be added). It just leaves the user more vulnerable on the cases where it’s expected to be used.
IIRC this change made apps like AdGuard, that rely on using user certs for blocking ads on Android apps, useless by default. So yeah… “attackers”, not “users trying to control what goes through their network”.
Tell it google. It doesn’t help anyone when you tell me or users on this forum.
agree
I don’t agree on this. Unfortunately many users just accept. And e.g. with fingerprint it is enough to tap once. It’s the same as on Windows where users just install a virus themselves (open the virus, ignore a warning that the file might be malicious and grant administrator rights) and tell the world they were hacked.
I also only found this out because I wanted to have a look at the traffic of an app and it didn’t connect anymore. In the first moment I thought they’d have implemented certificate pinning, but it just was this android stuff. Was able to bypass it with a magisk extension that basically installs user certificates as system certificates on boot.
It was just a comment, I’m sorry, this kind of babysitting bs can sometimes be too much.
Isn’t it obvious? You need to maintain a domain in the public namespace for certificates to be issued, it’s much cheaper/simpler to just add an entry to the DNS server you already have.
Well, I feel like this is beyond reasonable babysitting, I’d like to see someone install a root CA “by mistake”.
This is going off topic. Any chances that it will get fixed?
Regarding the certificate I’ve just installed a root certificate for ssl interception and it was only one fingerprint and one click on ok. That’s not much.
Any malicious app can easily convince many users to install a malicious certificate.
Ask the user for credentials pretending to be another app
Encrypt user data if access to storage is granted
Ask the user to uninstall the seafile app and install a fake one that eavesdrop all connections and can even get passwords for encrypted libraries (quite easily since seadroid is open source).
And none of those things require the user to authenticate to the OS. Any of these could also be achieved by someone having access to the unlocked device, and it won’t even ask for credentials once.
Using the “Any malicious app” argument is not fair to the discussion, because it assumes a critical condition in which many bad things could happen, and tricks you into thinking that whatever you do, as much as it could hurt usability and user freedom, it’s a good design choice as long as it “protects” the user from at least one thing.
I’d appreciate if this could reach the Play Store in less than three months from now (when cert renewal is due), given how small of a change it is, thanks @shoeper or the fast approval btw.
This won’t reach the play store. The version in play store is still 2.3.1, but you can download 2.3.4 and 2.3.3 from Github and F-Droid. They won’t update the play store App.
Because version 2.3.3 and 2.3.4 are still buggy on some Android versions. You can try the latest version, but if it doesn’t work, install 2.3.1 from Google Play.
