Hello Marcus, As Gluu Server can even run on self-signed cert ( just after completing the installation ); so your 'own CA' certificate shouldn't prohibit you to do SAML or any other transactions.

The problem occured when trying to download the metadata from the other machine via https (own CA which was added to the java keystore). I somehow got this to work, but not with the URL download method.

Which method did you end up using to get it to work?

I am sorry about my late replies. I downloaded the metadata file manually and uploaded the file to gluu. This worked fine for a while but now after retesting about a week later I get the following errors: Web Login Service - Unsupported Request and in the idp-process.log: ``` 2018-01-18 11:15:31,993 - INFO [org.opensaml.saml.common.binding.impl.SAMLMetadataLookupHandler:128] - Message Handler: No metadata returned for https://client.example.net/index.php/apps/user_saml/saml/metadata in role {urn:oasis:names:tc:SAML:2.0:metadata}SPSSODescriptor with protocol urn:oasis:names:tc:SAML:2.0:protocol 2018-01-18 11:15:32,009 - WARN [net.shibboleth.idp.profile.impl.SelectProfileConfiguration:111] - Profile Action SelectProfileConfiguration: Profile http://shibboleth.net/ns/profiles/saml2/sso/browser is not available for RP configuration shibboleth.UnverifiedRelyingParty (RPID https://client.example.net/index.php/apps/user_saml/saml/metadata) 2018-01-18 11:15:32,018 - WARN [org.opensaml.profile.action.impl.LogEvent:105] - A non-proceed event occurred while processing the request: InvalidProfileConfiguration ``` In the webserver's access.log is no entry of an attempted download of the metadata file. The way I used so far to get it back to working is reupload the metadata file to force a revalidation.

>but now after retesting about a week later I get the following errors: Web Login Service - Unsupported Request This doesn't seem like it's related to usual metadata issues. When there is no metadata for certain SPs, it will more clearly indicate that this service is not registered at this IDP. In your case I would check whether whatever is sent as request to IDP is of expected format and is sent to proper binding endpoint. May be some settings were changed at your SP.

I think this has to do with the _validUntil_ parameter of the metadata file. Otherwise the XML files are equal and no configuration changes have been made. As far as I understand Shibboleth should download the file from the _entityID_ URL before it expires. However it seems that it can't download the file because of this issue.

>As far as I understand Shibboleth should download the file from the entityID URL That's not the case. `entityid` is ephemeral string (it can be anything) and url is often used there mostly as an easy way to ensure its uniqueness. You set url from which to donwload metadata in oxTrust web UI when you choose to provide metadata by url there. This url is then pushed into IDP's configuration files and used by it to refresh metadata. So if you used "File" method for this TR, it won't be refreshing it automatically. Regarding your previous issue with inability to supply it by url with `https://` scheme - you said you added root CA's cert to Java's truststore. Which exactly truststore was it?

Thank you for the clarification! I added the the CA's certs to the `/opt/jre/jre/lib/security/cacerts` keystore as well as the systems keystores `/etc/pki/ca-trust/extracted/*` via `update-ca-trust`.

I don't see you mentioning you checked oxTrust's (`identity`) own logs during the failed attempt of adding it by url. Usually if there is a certificate issue it will be obvious if the log is checked (there will be Java error trace of some kind). If you'll try it at some point again, you should check it for clues. I'm still not sure what is your current issue. Did supplying metadata with correct "validUntil" property solve it?

The issue is still the Shibboleth URI with own CA problem. I thought I could fix it by using the file upload but I'd like a more automatic approach for downloading the file in regards to the metadata's validity. So back to URI mode: I just checked again and the only log entires (in `/opt/gluu/jetty` using `tail -fn 0 */logs/*`) are about LDAP connections: ``` ==> oxauth/logs/oxauth_persistence_ldap_statistics.log <== 2018-01-19 18:05:52,703 INFO [Thread-308] [xdi.oxauth.service.status.ldap.LdapStatusTimer] (LdapStatusTimer.java:97) - connectionProvider statistics: LDAPConnectionPoolStatistics(numAvailableConnections=3, maxAvailableConnections=10, numSuccessfulConnectionAttempts=3, numFailedConnectionAttempts=0, numConnectionsClosedDefunct=0, numConnectionsClosedExpired=0, numConnectionsClosedUnneeded=0, numSuccessfulCheckouts=630, numFailedCheckouts=0, numReleasedValid=630) 2018-01-19 18:05:52,703 INFO [Thread-308] [xdi.oxauth.service.status.ldap.LdapStatusTimer] (LdapStatusTimer.java:107) - bindConnectionProvider statistics: LDAPConnectionPoolStatistics(numAvailableConnections=1, maxAvailableConnections=10, numSuccessfulConnectionAttempts=1, numFailedConnectionAttempts=0, numConnectionsClosedDefunct=0, numConnectionsClosedExpired=0, numConnectionsClosedUnneeded=0, numSuccessfulCheckouts=0, numFailedCheckouts=0, numReleasedValid=0) 2018-01-19 18:05:52,703 INFO [Thread-308] [xdi.oxauth.service.status.ldap.LdapStatusTimer] (LdapStatusTimer.java:97) - authConnectionProvider#0 statistics: LDAPConnectionPoolStatistics(numAvailableConnections=1, maxAvailableConnections=1000, numSuccessfulConnectionAttempts=1, numFailedConnectionAttempts=0, numConnectionsClosedDefunct=0, numConnectionsClosedExpired=0, numConnectionsClosedUnneeded=0, numSuccessfulCheckouts=5, numFailedCheckouts=0, numReleasedValid=5) 2018-01-19 18:05:52,703 INFO [Thread-308] [xdi.oxauth.service.status.ldap.LdapStatusTimer] (LdapStatusTimer.java:107) - bindAuthConnectionProvider#0 statistics: LDAPConnectionPoolStatistics(numAvailableConnections=1, maxAvailableConnections=1000, numSuccessfulConnectionAttempts=1, numFailedConnectionAttempts=0, numConnectionsClosedDefunct=0, numConnectionsClosedExpired=0, numConnectionsClosedUnneeded=0, numSuccessfulCheckouts=1, numFailedCheckouts=0, numReleasedValid=1) ==> identity/logs/oxtrust.log <== 2018-01-19 18:05:55,223 INFO [Thread-591] [gluu.oxtrust.service.status.ldap.LdapStatusTimer] (LdapStatusTimer.java:97) - connectionProvider statistics: LDAPConnectionPoolStatistics(numAvailableConnections=2, maxAvailableConnections=10, numSuccessfulConnectionAttempts=2, numFailedConnectionAttempts=0, numConnectionsClosedDefunct=0, numConnectionsClosedExpired=0, numConnectionsClosedUnneeded=0, numSuccessfulCheckouts=898, numFailedCheckouts=0, numReleasedValid=898) ==> identity/logs/2018_01_19.stderrout.log <== 2018-01-19 18:05:55,223 INFO [Thread-591] [gluu.oxtrust.service.status.ldap.LdapStatusTimer] (LdapStatusTimer.java:97) - connectionProvider statistics: LDAPConnectionPoolStatistics(numAvailableConnections=2, maxAvailableConnections=10, numSuccessfulConnectionAttempts=2, numFailedConnectionAttempts=0, numConnectionsClosedDefunct=0, numConnectionsClosedExpired=0, numConnectionsClosedUnneeded=0, numSuccessfulCheckouts=898, numFailedCheckouts=0, numReleasedValid=898) ```

Are you sure oxTrust can connect to the server in this url? Can you ping the server **from inside container** by that name in url? Is there any hindrance between Gluu Server and this node (proxyies, firewalls etc)? Also consider rising [logs' verbosity](https://gluu.org/docs/ce/3.1.1/operation/logs/#log-levels) and try again. `identity/logs` directory is the only one you should be interested at the moment.

OK, I've increased oxTrust's log verbosity to DEBUG and there is still nothing related. Just tried `curl` inside the container and it works as expected. While looking for the log verbosity option I've found the setting for `caCertsLocation` which is set to the non-existing location `/usr/java/latest/jre/lib/security/cacerts`. I've tried setting it to `/etc/pki/java/cacerts` where the CA is included but this doesn't change the outcome. I'll finish for today and try to increase Shibboleth's log verbosity by the end of next week.

I think I've finally fixed it. If I enter the http (without s) URL, Gluu updates the Shibboleth configs even though this is just a redirect to the https site and this will not work with Shibboleth because of a different entityID used for the https site. Using https for the metadata URI will not update the config but just result in a Proxy Error and nothing useful in the log. However if I change Shibboleth's config by hand (`/opt/shibboleth-idp/config/metadata-providers.xml`) and replace http with https, Shibboleth fetches the metadata successfully on the next update. It seems to me that there is a bug in Gluu's config generation maybe using yet another certificate keystore?