Self Signed SSL login works for 6.9.1, does not work for 7.0, 7.x

[hgkamath]

I was on autoupdate on google-play-app-store Downgraded to 6.9.1 tried a few things. I'm going to not upgrade beyond 6.9.1 for a while.

Expected behavior

• start app
• fill in username, passwd, self-hosted ssl url
• dialog prompts to ask to allow self signed unverifyable ssl certificate, say yes,
• should login, for 6.9.1 site screen shows up, but does not for 7.0 and above

Actual behavior

• does not login after wordpress android app 7.0 vercode:376 upto 7.9.1-rc2
• login succeeds for 6.9.1 vercode:360 (apk retrieved from apkmirror)

Steps to reproduce the behavior

1) made fresh self signed CA certificate and server certificate create a cacert.pem, priv.key, host.crt, host.key as described in http://www.eclectica.ca/howto/ssl-cert-howto.php 2) desktop: add certificate to firefox on desktop browser 3) desktop: check that wordpress working from desktop browser 4) android: add cacert.pem into android settings->general->security->certificates->user 5) android: check that wordpress site working from android browser 6) install and try each wordpress apk

App logs uploaded for both cases wp70_log.txt wp691_log.txt

Repeated a few times to be sure 7.0, vercode:376 was released on Apr-4-2017: API:16-25 6.9.1, vercode:360 was released on Mar-28-2017: API:16-25 I had not noticed this sooner as had not used wordpress app on phone for a while

Tested on [device], Android [version]

LG G3 D855 Android 6.0 lollypop V30b-GLOBAL-COM

[maxme]

@hgkamath , thanks for this super detailed description. I'll have a look at the problem ASAP.

Note: it's supposed to be supported in 7.x and our network layer supports it. Likely something wrong in the app.

[maxme]

In the 7.x logs, I see:

SSLPeerUnverifiedException: Hostname XXX.XXX.XX.XX not verified

@hgkamath are you entering your IP address directly like https://192.168.0.1 in the site URL when you try to sign in? I think that's the problem, the hostname defined in the SSL cerficate is different from that address.

I'm not sure what Web browsers do, maybe they ignore the hostname when the certificate is added as an exception (we could do that).

[hgkamath]

I apologize for late reply. I just checked page after many days.

your hunch could be in the right direction. Browsers don't seem to have a trouble with IP:port and hostname issues.

As mine is a simple self-hosted setup, client:laptop to server:PC on home wifi, i haven't made official dns/nis hostnames other than a mention in /etc/hostname which too I seldom use. As a one person user, its much simpler to just access using https://IP:port. subtleties:

• I made the ssl certificate with the CN to have the same name as the httpd "serverhost" directive, otherwise apache httpd server will complain and not start as it would say SSL certificate does not match serverhost directive.
• Since the apache vhost is on 8443 rather than regular 443, the port name has to be specified along with the IP address or hostname. There are many other port based vhosts (as opposed to name based vhosts) also using their own SSLs. This one just has the word press server and an nextcloud server. The combination string "hostname:port" is strictly speaking not just hostname. So making a ssl certificate on just hostname creates ambiguity between different vhosts on different ports as each Vhost has its own SSL certificate directive.

The above ssl-cert-howto link says "The Common Name must be (or the IP address must resolve to) the server name your clients use to contact your host. If this does not match, every time they connect your clients will get a message asking them if they want to use this server. In effect, the client software is saying, "Warning! You asked for mail.sample.com; the responding machine's certificate is for smtp.sample.com. Are you sure you want to continue?""

so which is why I think think naming should not be strict, and if a User really wants to

So maybe there needs to be a stored "I accept the consequences" setting for each separately or combined for each of the issues of self-signed certificates

• one to accept a self-signed certificate without needing a installed-selfca-certificate on the client. (I don't fully understand the security rationale but some recent clients mandatory ask for for a local selfca certificate without which it won't proceed). Previously I wouldn't bother about trying to be a selfCA and install selfCA-certs, and could skip that step. The warning dialog in the firefox-browser would come, I would select make and add server as an exception and continue. The icon next to the favicon in the url-bar would just indicate it isn't truly signed certificate, but the website would work just fine.
• one to accept self-signed certificate without a chain of trust to linked only to a user cert. In this case the browser has a green-lock icon in the address bar when the ssl verifies against the self-CA cert.
• one to accept whatever be the IP/hostname/port and vhost/serverhost. The firefox browser doesn't seem to care about this once the exception is added. I think either the wordpress client should either do so too, or ask for a second confirmation and exception to store.

This happens quite commonly in internal/private/self hosted/non public setups. One wonders why SSL is needed at all.

• maybe perhaps so that network traffic cannot be sniffed and read, but as one would point out, without hostname verification lot of things can be made to happen. but this is a private self hosted setup.
• for many web-apps services, SSL mandatory turned on, with no way to disable them (like nextcloud)

[hgkamath]

I tried making several certificates to see if somehow something would accept.

• CN=<hostname> this gives a problem because https wants the ssl CN to be the same as the httpdvhostservername
• CN=<httpdvhostservername> this gives a problem perhaps because I am accessing server via ipv4 address and have not made the hostnames or httpdvhostservernames resolvable. On some browsers on desktops, i think making and saving an exception is sufficient to push through.
• CN=XXX.XXX.XX.XX:Port this gives a problem because maybe browsers expect ipaddr/hostname in url to be same as that in certificate. The port no is extraneous.
• CN=XXX.XXX.XX.XX this used to work on wordpress 6.9.1 after confirming "the unverified ssl warning dialog box"

Wordpress-8.0 seems to have an additional problem in "Its New Login Experience" Additionally, my wordpress site is hosted on a location-path /wordpress from the httpd document root The wordpress app, perhaps cannot even reach the /wordpress/xml-rpc.php path the httpd access logs show: XXX.XXX.XX - - [20/Aug/2017:17:05:20 -0400] "GET / HTTP/1.0" 400 362 "-" "-" This additional issue maybe ought to be a bug on its own.

Summarizing the peculiarities of my setup

• no DNS, no resolved hostnames. / ip addresses only,
• SSL self CA, self-signed certificate, cacert.pem is file-transfered to clients.
• non standard port 8443, apache webserver, port based vhost with a servername, which has SSL enabled and certificate specified
• hosted on location /wordpress
• served via php-fpm, using rewrite and proxy directives
• server certificate CN uses ip address (no port or path)

nextcloud client hosted on /nextcloud works with no issues

[hgkamath]

wordpress-mobile/wordpress-android uses android.webkit

---

SSL certificate using SAN field The below apply if one were using a ssl certificate with extended SAN field in addition to the CN. I am not. I am using only a CN

http://unmitigatedrisk.com/?p=381

Chrome 58 - Not secure, certificates must have Subject Alternative Name, not supporting self signed certificate without SAN https://www.reddit.com/r/sysadmin/comments/677hep/chrome_58_not_supporting_self_signed_certificates/ https://bugs.chromium.org/p/chromium/issues/detail?id=308330

https://bugzilla.mozilla.org/show_bug.cgi?id=1245280 since firefox-48, if san is present, it won't fall back to common name

[ v3_req ] subjectAltName = @alt_names ...

[ v3_ca ] subjectAltName = @alt_names ...

[ alt_names ] # DNS.1 = example.com IP.1 = XXX.XXX.XX.XX

https://cabforum.org/guidance-ip-addresses-certificates/ https://wiki.mozilla.org/CA/Required_or_Recommended_Practices

https://www.ietf.org/rfc/rfc3280.txt RFC 3280: 4.2.1.7 Subject Alternative Name https://www.ietf.org/rfc/rfc5280.txt

usually the common-name is repeated as the first san https://cabforum.org/guidance-ip-addresses-certificates/

---

SSL certificate for public IP address https://serverfault.com/questions/193775/ssl-certificate-for-a-public-ip-address

[hgkamath]

workaround seems to be

• install a self-CA cerficate
• create a CSR/key/cert with SAN field, ( CN=httpd_vhost_servername <- ignored as per standard )

The bug seems to be that the "accept exception" option isn't really working like it is supposed to , in a manner similar to nextcloud-app/android-android browsers

I do think, however, that when user wants to make a self-signed exception, user really means to make an exception regardless of how improper the certificate is.

There seems to be 6 kinds of Allows (1) no SSL (2) proper SSL with verification against system global-CA-certificates (3) self-signed SSL SAN-field certificate with verification against user installed self-CA-certificate (4) self-signed SSL CN-only certificate with verification against user installed self-CA-certificate (5) stored exception: self-signed SSL SAN-field certificate with server exception without self-CA verification (6) stored exception: self-signed SSL CN-only certificate with server exception without self-CA verification

My issue - previously i was doing (6), problem started with wordpess-7, first switched to (4), didn't work, then switched to (3) which seems to work

Apps involved desktop: firefox, nextcloud-client android: firefox, chrome, brave, nextcloud, wordpress

• My previous mentioning of the android browsers which seemingly did trusted acceptance of CN-only certificate verification against selfCA-certfiicate was perhaps spurious. maybe it was browser cache verification, maybe a human misread, I can't replicate that.

• Desktop browsers, nextcloud seem to be more lenient in accepting a self-signed CN-only IP certificate, they can either verify against the installed selfCA-certificate or can be made to accept an exception for the server. Basically they do everything upto (6). They only ignore the CN if the SAN-field is present.

• The android browsers behave a bit differently from desktop browsers. Android browsers (Firefox, chrome, brave), unlike desktop browsers do not auto-verify CN-only IP certificate against installed selfca-certificate, but they do autoverify and allow to self-signed certificate with SAN field. They can't seem to do (4), but one can however make proceed by making an exception as in (5),(6) as they allow user exceptions.

• The next cloud app is okay, It may not be able to verify the CN-only certificate, but it can proceed with a stored exception.

• The wordpress app, in particular cannot do (4),(5),(6)

• The CN-only self-signed certificates (4),(6) are suggested to be deprecated in favor of SAN fields, but imho not completedly banned. The CN field is ignored if the SAN field is present.

• the wordpress app, make exception options (5),(6), do not seem to properly invoked. the app log says "cannot get xmlrpc.php". The httpd server access log says "GET / HTTP/1.0" 400 362, Can't tell cause-or-effect of SSL failure and the sub url-path /wordpress issue.

On Wordpress-8.0, otherwise so far app looks good, works as expected

[mzorz]

awesome! Thanks for the thorough report! Will keep an eye on this

[stale[bot]]

This issue has been marked as stale because:

• It has been inactive for the past year.
• It isn't in a project or a milestone.
• It hasn’t been labeled [Pri] Blocker, [Pri] High, or good first issue.

Please comment with an update if you believe this issue is still valid or if it can be closed. This issue will also be reviewed for validity and priority (cc @designsimply).

[designsimply]

The bug seems to be that the "accept exception" option isn't really working like it is supposed to

@hgkamath am I understanding correctly that this is only the case if the hostname defined in the SSL certificate is different from the IP address you are entering in the app to log in and that option (3) to use a self-signed SSL SAN-field certificate with verification against user installed self-CA-certificate is an acceptable workaround for you?

[hgkamath]

I don't have the setup to test presently, but I reply from memory. Yes, configuration (3) became my workaround for the original configuration of (6) and was acceptable workaround, the grudge being that it made things more tedious The bug was in android-wordpress-app. problem started with the its upgrade. Nothing else was changed and the android-nextcoud-app did not have any issue.

It used to be the case that, for self signed test servers, one had to just quickly create an self-signed SSL certificate. with the vhost name and get the clients (android-security/browser) upon first connection to accept the SSL as an exception, and also permanently store the exception, which they would with no fuss.

machine/server were accesssed using a port based vhosts https[colon]//ipv4-address:portno/wordpresspath There is no name resolution on the client

After the upgrade, things stopped working. In order to make things work I had to do two things 1) copy the self CA certificate to client machine and include it in the client pre-installed certificate lists in the android-security/browser 2) change the way the SSL was made from CN-only to using a san field

Both the above changes were not intuitive, and only came to know after much reading and experimenting. I think configuration (6) is the typical way in which things are done for a private test server. This isn't a security lapse because no-one sets-up such self-signed server for public or accepting self-signed certificates for arbitrary public servers.

nb. I have not tested since then, so I cannot say if subsequent updates undid the problem. I think it unlikely, but I speculate if this extra work is now some sort of new best practice of making things secure/stringent The phrasing is apt : The bug seems to be that the "accept exception" option isn't really working like it is supposed to

[stale[bot]]

This issue has been marked as stale because:

• It has been inactive for the past year.
• It isn't in a project or a milestone.
• It hasn’t been labeled [Pri] Blocker, [Pri] High, or good first issue.

Please comment with an update if you believe this issue is still valid or if it can be closed. This issue will also be reviewed for validity and priority during regularly scheduled triage sessions.