show solutions to the following questions.

There are several paths to resolution for these types of errors:
 Run the Install-WebApplicationProxy cmdlet again to clear up configuration issues.
 Confirm network connectivity to the AD FS server from the Web Application Proxy server.
 Verify that the WebApplicationProxy service is running on the Web Application Proxy server.
Supporting non-SPI-capable clients
Server Name Indication (SNI) is a feature of Secure Sockets Layer (SSL) Transport Layer Security (TLS)
that is used in Web Application Proxy server and AD FS to reduce network infrastructure
requirements. Traditionally, an SSL certificate had to be bound to an IP address/port combination. This
meant that you would need to have a separate IP address configured if you wanted to bind a different
certificate to the same port number on a server. With the use of SNI, a certificate is instead bound to
the host name and port, allowing you to conserve IP addresses and reduce complexity.
It's important to realize that SNI relies on the requesting client supporting SNI. If the SSL Client Hello
doesn't contain the SNI header, http.sys won't be able to determine which certificate to offer the client
and will reset the connection.
Most modern clients support SNI, but there are some clients that tend to cause issues. Generally,
older browsers, legacy operating systems, hardware load balancers, health probes, older versions of
WebDAV, ActiveSync on Android, and some older VoIP conferencing devices might be non-SNIcapable devices.
If it is necessary to support non-SNI clients, the easiest solution is to create a fallback certificate
binding in http.sys. The fallback certificate needs to include any fully qualified domain names (FQDNs)
that may need to be supported, including the FQDN for the AD FS service itself (adfs.contoso.com),
the FQDN of any applications published via Web Application Proxy (mail.contoso.com), and the FQDN
to support Enterprise registration (enterpriseregsitration.contoso.com) if you are using Workplace
Join.
When you have generated the certificate, get the application GUID and certificate thumbprints in use
by using the following Windows PowerShell cmdlet:
Get-WebApplicationProxyApplication | fl Name,ExternalURL,ExternalCertificateThumbprint
Now that you have the application GUID and certificate thumbprint, you can bind it to the IP wildcard
and port 443 by using the following syntax:
netsh http add sslcert ipport=0.0.0.0:443 certhash=certthumprint appid={applicationguid}
Note that you will need to run this on each server in the AD FS farm as well as on any Web
Application Proxy server.
More info You can find technical details on SNI as a subsection of the TLS Extensions RFC The table on TechNet offers the following suggestion for event 12021:
Make sure that the certificate thumbprints that are configured for Web Application Proxy applications
are installed on all the Web Application Proxy machines with a private key in the local computer store.
Armed with this information, you can review the certificates on the Web Application Proxy server to
ensure that they have the correct names and expiration dates, and that the thumbprint matches the
one on the server. Then, you can review the certificates on the server, ensure that they are correct, and
reissue them if they are incorrect.
Certificate issues
Certificates play an important role in AD FS and Web Application Proxy. Getting the proper
certificates—with the correct names in the certificates on the appropriate machines—is therefore
critical to getting Web Application Proxy to function correctly with AD FS.
You might see issues with certificates manifested in error messages like the following:
The trust certificate ("ADFS ProxyTrust - WAP01") is not valid.
There are several possible causes of this issue:
 There might be some sort of network interruption between the Web Application Proxy server and
the AD FS server.
 The Web Application Proxy server might have been down for an extended period of time.
 There might be an issue validating the certificate due to problems in the CA infrastructure.
 Time synchronization issues between the Web Application Proxy and AD FS servers might cause
them to be out of synchronization.
To resolve these problems, verify the time settings on the Web Application Proxy and AD FS servers
and then rerun the Install-WebApplicationProxy cmdlets.
Configuration data in AD FS is inconsistent or corrupt
You might also encounter errors for which the configuration data in AD FS could not be found or the
data is unusable to the Web Application Proxy server. This can result in errors such as
Configuration data was not found in AD FS.
or
The configuration data stored in AD FS is corrupted or Web Application Proxy was unable to parse it.
or:
Web Application Proxy was unable to retrieve the list of Relying Parties from AD FS.
Several things can cause these errors. It's possible that Web Application Proxy was never fully installed
and configured, or there were changes that occurred on the AD FS database that resulted in
corruption. It's also possible that the AD FS server cannot be reached due to a network issue and
therefore the AD FS database is not readable.