[BUG] Valid personal certificate detected as invalid on seadroid

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.

(Screenshots in spanish)
This is on seadroid:

And this is on Chrome:

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.

Which version are you using?

Version is 2.2.1 for that client

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.

1 Like

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.

I think the disadvantages are clear.

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 as of Android Nougat they are still NOT trusted.

See Android Developers Blog: Changes to Trusted Certificate Authorities in Android Nougat

Looks like the the following change could be applied to the app to allow user defined CAs:

<network-security-config>  
      <base-config>  
            <trust-anchors>  
                <!-- Trust preinstalled CAs -->  
                <certificates src="system" />  
                <!-- Additionally trust user added CAs -->  
                <certificates src="user" />  
           </trust-anchors>  
      </base-config>  
 </network-security-config>

But you can also run a public domain in a private network and also use LE certificates as long as you can connect to the internet (DNS challenges).

I think the changes from google are mainly against attackers tricking the user into installing a certificate to allow TLS interception afterwards.

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”.

And the disadvantage would be?

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?

1 Like

As far as I see only the above is needed in some network configuration. You can submit a pr on the seadroid repository and see if it’s getting merged.

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.

The

argument can apply to many things. For example:

  • 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.

1 Like


Waiting for it to be pulled.

1 Like

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.

What is the reason for this? Don’t developers use/support the Play Store anymore?

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.

2 Likes