It's very strange that the `Sp Metadata URL` is not `https`.

Hi, Ved. I suspect due to some issue with name resolution oxTrust can't reach document at mentioned url during metadata validation phase. We've had such issues before with some users whose Gluu machines were placed inside internal organization's network with strict firewall rules. Approach was reconsidered and in next releases it will fall back to local validation if external schema documents can't be reached. By default, Gluu components will use Google's DNS server `8.8.8.8` to resolve DNS names in case they need to contact any host in external network. That's what is put by default into `/etc/resolv.conf` inside container. Some organizations may block outgoing DNS traffic, forcing internal machines to use their own controlled internal DNS servers instead. Others may block all outgoing HTTP traffic unless it's routed through some kind of proxy which requires authentication. Please provide output of next commands for now (from inside Gluu container): 1. `# cat /etc/hosts` 2. `# cat /etc/resolv.conf` 3. `# ping 8.8.8.8` 4. `# ping www.w3.org` 5. `# wget www.w3.org` 6. `# hostname`

I also agree with Michael's point. It's even more strange that their assertion consumer endpoints also don't use `https://` scheme. You may want to explicitly set mandatory encryption for assertions and nameids in your SAML responses for this TR, Ved (if this SP supports this feature, of course). Please check [this page](https://gluu.org/docs/ce/3.0.1/admin-guide/saml/#relying-party-configuration) on how to configure custom Relying Party settings. You'll need to add "SAML2SSO" profile to the list, and set "encryptAssertions" and "encryptNameIds" to "always"

Thanks Aliaksandr and Michael for helping out. I really appreciate it. Just to give you context about the environment.Both, ServiceProvider and Gluu server is running in a private network. @Aliaksandr - here's the output of the commands that you asked for: # cat /etc/hosts > [root@imcgluu ~]# cat /etc/hosts > 127.0.0.1 localhost > ::1 ip6-localhost ip6-loopback > ff02::1 ip6-allnodes > ff02::2 ip6-allrouters > 192.168.33.10 imcgluu.com > 10.0.2.2 imchippo.com # cat /etc/resolv.conf > [root@imcgluu ~]# cat /etc/resolv.conf > # Generated by NetworkManager > nameserver 8.8.8.8 > search local # ping 8.8.8.8 > [root@imcgluu ~]# ping 8.8.8.8 > PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. > 64 bytes from 8.8.8.8: icmp_seq=1 ttl=63 time=18.1 ms > 64 bytes from 8.8.8.8: icmp_seq=2 ttl=63 time=36.7 ms > 64 bytes from 8.8.8.8: icmp_seq=6 ttl=63 time=17.1 ms > ^C > --- 8.8.8.8 ping statistics --- > 6 packets transmitted, 6 received, 0% packet loss, time 5026ms > rtt min/avg/max/mdev = 17.151/20.931/36.736/7.077 ms # ping www.w3.org > [root@imcgluu ~]# ping www.w3.org > PING www.w3.org (128.30.52.100) 56(84) bytes of data. > 64 bytes from hans-moleman.w3.org (128.30.52.100): icmp_seq=1 ttl=63 time=22.1 ms > 64 bytes from hans-moleman.w3.org (128.30.52.100): icmp_seq=2 ttl=63 time=21.5 ms > 64 bytes from hans-moleman.w3.org (128.30.52.100): icmp_seq=3 ttl=63 time=24.9 ms > 64 bytes from hans-moleman.w3.org (128.30.52.100): icmp_seq=4 ttl=63 time=24.2 ms > 64 bytes from hans-moleman.w3.org (128.30.52.100): icmp_seq=5 ttl=63 time=24.7 ms > ^C > --- www.w3.org ping statistics --- > 5 packets transmitted, 5 received, 0% packet loss, time 4018ms > rtt min/avg/max/mdev = 21.591/23.537/24.915/1.403 ms # wget www.w3.org > [root@imcgluu ~]# wget www.w3.org > --2017-05-26 16:03:49-- http://www.w3.org/ > Resolving www.w3.org (www.w3.org)... 128.30.52.100 > Connecting to www.w3.org (www.w3.org)|128.30.52.100|:80... connected. > HTTP request sent, awaiting response... 200 OK > Length: 38090 (37K) [text/html] > Saving to: ‘index.html’ > > 100%[======================================================================================================================================================================================>] 38,090 --.-K/s in 0.03s > > 2017-05-26 16:03:50 (1.43 MB/s) - ‘index.html’ saved [38090/38090] # hostname > [root@imcgluu ~]# hostname > imcgluu.com Also, as both of you pointed out, I updated the Sp Metadata URL to https. The Sp Metadata URL* is **https://imchippo.com:9000/saml/metadata** Now when I'm trying to Activate the Trust Relationship, I don't see the metadata validation error, but still the status is InActive. Here's screenshot of the console [InActive](https://www.dropbox.com/s/oe8dgyc82wxx4wc/InActive_TR.png?dl=0) [Relationship Config](https://www.dropbox.com/s/a1o7wd1a16gd565/TR_Details.png?dl=0) [SP Metadata](https://www.dropbox.com/s/6y6kwra5zkyr65j/sp.xml?dl=0) FYI, when I'm trying to wget the SP metadata from inside the Gluu container, I'm seeing **SSL handshake error**. > [root@imcgluu ~]# wget https://imchippo.com:9000/saml/metadata > --2017-05-26 16:11:43-- https://imchippo.com:9000/saml/metadata > Resolving imchippo.com (imchippo.com)... 10.0.2.2 > Connecting to imchippo.com (imchippo.com)|10.0.2.2|:9000... connected. > ERROR: cannot verify imchippo.com's certificate, issued by ‘/C=US/ST=NY/L=NY/O=XYZ/OU=Tech/CN=imchippo.com’: > Self-signed certificate encountered. > To connect to imchippo.com insecurely, use `--no-check-certificate'. May be the status is InActive because of SSL handshake error. How do I get the SSL handshake going ? Where & how should i add the certificate to the truststore of Gluu server? Again, thanking in advance for any guidance/help. Thanks Ved

Hi, On digging in further, I was able to connect,from inside Gluu container, to SP over SSL/TLS layer using openssl client tool and was able to view the certificate details. > openssl s_client -connect imchippo.com:9000 -debug > openssl s_client -showcerts -connect imchippo.com:9000 So connectivity should not be the issue here. I was going over the server log files /opt/gluu/jetty/identity/logs/oxtrust.log , which has below logs > 2017-05-27 20:20:57,483 DEBUG [pool-2-thread-2] [org.gluu.oxtrust.ldap.service.MetadataValidationTimer] (MetadataValidationTimer.java:87) - Starting metadata validation > 2017-05-27 20:20:57,484 TRACE [pool-2-thread-2] [org.gluu.oxtrust.ldap.service.MetadataValidationTimer] (MetadataValidationTimer.java:119) - Starting metadata validation process. > 2017-05-27 20:20:57,484 DEBUG [pool-2-thread-2] [org.gluu.oxtrust.ldap.service.MetadataValidationTimer] (MetadataValidationTimer.java:92) - **Metadata validation finished with result: 'false'** Can any one point me the log files where I can find more details about as to why the metadata validation process is failing ? Thanking in advance for any help. Ved

Thanks, Ved. When I create TR with your metadata using "File" supply method, it passes validation in my 3.0.1 instance. That's strange, taking into account your error in the 1st post and the fact name resolution seems to work fine in the container and you seem to be able to access that remote web server with wget either.. Just to be sure, could you also try to run this inside container? `# wget http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd`; then check the file, make sure it's indeed an xml document and not some kind of html error page. Are you sure you are not limiting access to internet from inside your network? I guess this also could be some intermittent connectivity issue. Could you try to delete the TR, recreate again, delete, recreate etc, several times in a row, just to see whether it's reproducible? Also, please re-run this wget command before starting this test, to be sure connectivity is ok at this very moment. >Also, as both of you pointed out, I updated the Sp Metadata URL to https. The Sp Metadata URL* is https://imchippo.com:9000/saml/metadata >Now when I'm trying to Activate the Trust Relationship, I don't see the metadata validation error, but still the status is InActive. >May be the status is InActive because of SSL handshake error. Yes, I also suspect this is the cause. This time it most likely wasn't able to even establish connection and get the metadata, so validation phase didn't even start. In that case some Java exception should appear in `/opt/gluu/jetty/identity/logs/oxtrust.log`, so you could delete the TR, create it again while doing `tail -F` to this log file, waiting for any clues. >Where & how should i add the certificate to the truststore of Gluu server? You need to fetch SSL certificate in question and put it into, say, `~/imchippo-sll.crt` inside container. Then run this command: `# keytool -import -alias imchippo_sll -trustcacerts -file ~/imchippo-sll.crt -v -keystore /opt/jdk1.8.0_112/jre/lib/security/cacerts -storepass changeit`

> connectivity should not be the issue here. Most likely the issue is with certificate of the `imchippo.com:9000` server which is not trusted by oxTrust. Please follow guidance above to add it to Java's default trust storage. Then restart oxTrust - `# service identity restart` - do the `tail -F /opt/gluu/jetty/identity/logs/oxtrust.log`, delete the TR, create it again and observe what errors will pop up this time (hopefully metadata will be acquired this time)

Hi Aliaksandr, At the outset let me thank you for your help. I was able to get the TR into active status. I'm writing the steps which I had done. I'm not sure though which step worked in resolving it. After verifying SSL communication between SP and Gluu, with TR status still as inactive,I did these steps: 1) Install and ran ntpdate to do time synchronisation inside Gluu container. 2)Rebooted Gluu host OS 3) Tried Activating TR again. Noticed below logs in /opt/gluu/jetty/identity/logs/oxtrust.log 2017-05-27 21:44:23,279 ERROR [qtp274064559-11] [org.gluu.oxtrust.ldap.service.TrustService] (TrustService.java:385) - Failed to send the notification email: java.lang.NullPointerException: null at java.util.Hashtable.put(Hashtable.java:459) ~[?:1.8.0_112] at org.gluu.oxtrust.util.MailUtils.sendMail(MailUtils.java:68) ~[classes/:?] at org.gluu.oxtrust.ldap.service.TrustService.updateReleasedAttributes(TrustService.java:378) [classes/:?] <<snip>> <<snip>> at org.gluu.oxtrust.ldap.service.TrustService_$$_javassist_seam_13.updateReleasedAttributes(TrustService_$$_javassist_seam_13.java) [classes/:?] at org.gluu.oxtrust.action.UpdateTrustRelationshipAction.save(UpdateTrustRelationshipAction.java:331) [classes/:? 4) So I Delete TR 5) Created new TR with no Release Attribute and activated it 6) This time TR validation passed and the status became active 7) Updated TR with 'email' attribute and activated it again. 8) TR passed validation and was active Note, I didn't add SP ssl cert to Gluu trustore which is raising a question - How is the Gluu server trusting SP when it does not have SP certificate it its truststore ? Thanks Ved