We had this behavior too when we started with AAF. Turned out that the web servers SSL certificate chain wasn't complete.

On most Android phones enrollment wasn't possible, but on iPhones.

Check the server certificate using an online SSL tool like SSLlabs or something similar.

cheers Werner

Our issue was that the webserver certificate didn't contain the full chain.

OK, 

Can anyone inform me where I can get the full chain?  Where I can get the requirements for the AA Server?  According to: https://www.netiq.com/documentation/advanced-authentication-63/smartphone-applications/data/t481aiz1lpqz.html

I will need to combine the:

1).  Private Key (from the appliance)

2).  Domain Certificate (I think also known as: Server Certificate from Godaddy)

3).  Intermediate Certificate (I thought the bundle certificate from Godaddy)

4). Trusted Root certificate (I thought the bundle cert from Godaddy included this certificate)

But I am not sure where to get this information.  Is GoDaddy supposed to provide all of these files separately?  https://ssl-ccp.godaddy.com/repository?origin=CALLISTO

Are we able to obtain these files from the \bin\ - folder of the AA Server Appliance?  Where can we obtain these required files to get the Android phones to enroll for 2FA with our AA Server Appliance?

What kind of Web Server is the Adv. Authenticatin Server using (Tomcat?) ?

What kind of operating system is the Server using?

I needed to verify the certificate(s) provided by Godaddy can match up cert by cert as indicated exactly on the MicroFocus Suggested fix:
https://www.netiq.com/documentation/advanced-authentication-62/smartphone-applications/data/t481aiz1

Godday informed me that I should reference: https://aboutssl.org/go-daddy-root-certificates/ to verify.

Everything matched up except for the gd_bundle-g2-g1.crt

This bundle had 3 certificates inside it:
1st cert - matched up with the web site https://aboutssl.org/go-daddy-root-certificates
2nd certificate did not match up anywhere.
3rd cert match up with the gdig2.crt.pem (pem) from: https://aboutssl.org/go-daddy-root-certificates/

The 3rd certificate in the bundle was the trusted root certificate, that MicroFocus asked for.

1). I have the private key. - Verified (.key file from appliance.
a. Verified to work with GoDaddy domainname cert.
b. https://www.sslshopper.com/certificate-key-matcher.html.

2). Domain certificate. - Verified (.crt from GoDaddy)
a. Verfiied to work with the .key file.
b. https://www.sslshopper.com/certificate-key-matcher.html.
c. So the 2nd part is verified and it is provided from godaddy to work.

3). Intermediate Certificate
a. The 1st certificate in this chain file and only that 1st cert. matches gdig2.crt.cer
from: https://aboutssl.org/go-daddy-root-certificates/
b. There are 3 different parts of the bundled certificate.
c. The MicroFocus Web page that lists the fix ( https://www.netiq.com/documentation/advanced-authentication-62/smartphone-applications/data/t481aiz1 )
only has 1 -- Beg Cert-- -- End Cert --- entry for the intermediate.
d. I just added the 1st certificate entry for the intermediate chain part.
e. That same cert was also found in the 2nd table of the web page, GoDaddy Secure Server Certificate (Intermediate Certificate) – G2 gdig2.crt.pem (pem)

4). Trusted Room Certificate - Verified
a. The last certificate in the bundle gd_bundle-g2-g1.crt from GoDaddy.
b. I was told that gd-class2-root.crt from https://aboutssl.org/go-daddy-root-certificates/ (1st link)
"GoDaddy Class 2 Certification Authority Root Certificat" is the trusted root certificate.
c. This matches the last --beg end cert -- from the bundle provided by godaddy that we downloaded.
d. Verified to match G2 gdig2.crt.pem (pem) https://aboutssl.org/go-daddy-root-certificates/
c. So the trusted root certificate is verified from what Godady provided us.

I had the same problem, with v6.4.

Documentation https://www.netiq.com/documentation/advanced-authentication-63/smartphone-applications/data/t481aiz1lpqz.html says to make sure the chain on the appliance in the "SERVER OPTIONS" is correct. Hower this is only part of the solution. If you use an external address with the suggested nginx loadbalancer you have to make sure that your chain is also complete on your loadbalancer configurations.

The nginx config has to have the all certificates:  yourHostnameCert, IssuingCA(s), RootCA in PEM format. Not sure if the order is important, but it worked for me with this order.

ssl_certificate /etc/ssl/certs/fullchain.pem;
ssl_certificate_key /etc/ssl/private/your-HostnameCert.key;

if your not sure that you have set up the external address correctly you can use the ssl labs https://www.ssllabs.com/ssltest/index.html site to verify your setup. If you get an A rating all is well. 
I got a B rating and the details stated that the chain was not properly set.