The reason why config pages are on http and not https is the fact that part of the process could be also importing the CA cert. So that the workflow to import the ca cert doesn't need to involve working around the cert error. On the other hand it doesn't increase security - it's more UX thing.

With the change of the pages to communicate with IPA API to get i18n messages. This becomes indeed a problem (this bug).

Approaches I see are:
change configuration worklow so that import of CA cert is done differently. This is solved by IPA enabled system where the cert is added by ipa-client-install to a central store. For others, I know what could be the solution where the page would be still localized
allow http for i18n messages API end point.

I don't like any.

IMHO there 3 problems mixed at one:
1) actually, a user cannot visit the 'non-https' version of IPA login page. Thus a user always has the 'https' one, but cannot follow 'http' link for 'ssbrowser.html' (this issue);

2) as for now there is no implementation to provide redirection to 'ssbrowser' in case of some kind of CA cert problem;

3) 'http' version 'ssbrowser' is not operational due to i18n messages as you mentioned;

For now, only the 1st issue can be easily fixed.
https://github.com/freeipa/freeipa/pull/2745

master:

• e3f3796 Don't use cross-origin request