Difference between revisions of "Troubleshoot Connectivity"

From regify WIKI
Jump to navigation Jump to search
 
(15 intermediate revisions by the same user not shown)
Line 22: Line 22:
  
 
=== What domains do I need to white-list for regify usage? ===
 
=== What domains do I need to white-list for regify usage? ===
 +
 +
Try this tool to get all domains that need to be white-listed for regify usage:<br>[http://www.regify.com/checkWhitelist.php regify tool to determine domains for regify usage]
 +
 
This only applies if you are using a proxy-server that blocks Internet access to all sites that are not white-listed. In general, using regify behind such a restricted proxy is not very comfortable. This is because
 
This only applies if you are using a proxy-server that blocks Internet access to all sites that are not white-listed. In general, using regify behind such a restricted proxy is not very comfortable. This is because
 
# The networked regify system is a multi-provider system with many regify providers behind several Internet domains. Thus, the domains to white-list may vary.
 
# The networked regify system is a multi-provider system with many regify providers behind several Internet domains. Thus, the domains to white-list may vary.
Line 29: Line 32:
 
If you are affected by such CRL issue, your debug log (regify client, regibill, regipay) or diagnostics log (regibox) is showing entries like "Unknown error 0x80092013" or similar. In such case, mostly the log shows an error message saying that the certificate revocation list was offline or nor available.
 
If you are affected by such CRL issue, your debug log (regify client, regibill, regipay) or diagnostics log (regibox) is showing entries like "Unknown error 0x80092013" or similar. In such case, mostly the log shows an error message saying that the certificate revocation list was offline or nor available.
  
In this case, you need to whitelist all relevant CRL locations on your proxy server.
+
In this case, you need to whitelist all relevant CRL locations on your proxy server. You also may have a look below about error 52.
 
 
<u>'''Automatically determine needed locations'''</u>
 
 
 
[http://www.regify.com/checkWhitelist.php regify tool to determine domains for regify usage]
 
 
 
<u>'''Follow these steps to manually get all needed domains to white-list:'''</u>
 
* In general, regify needs access to all '''*.regify.com''' domains. This is for using the PLS (Provider Lookup Service) and for automatic updates etc.<br>
 
* In addition, you need to white-list the '''domains of your regify provider'''. These domains depend on the regify provider your regify account is registered at.<br>
 
* In addition, if your proxy does not resolve automatically, you need to white-list '''the domains of the certificate revocation lists''' (CRL) used in the affected certificates. For the *.regify.com certificates, this are <br>''http://crl.comodoca.com/COMODORSADomainValidationSecureServerCA.crl'' and <br>''http://crl.comodoca.com/COMODORSACertificationAuthority.crl''.
 
* It is very likely that you also have to add '''the CRL of the regify provider you are connecting to'''. In most cases, you are able to get the domains from the certificate information you can get from your web-browser.
 
* For regibox usage, you also need to white-list '''all domains of regify providers that are hosting a box your users are members of'''. If a user A of your regular provider A becomes a member of a regibox created by user B of provider B, your user A also needs access to the provider B domains. You also might need to add the CRL's of them, too (see above).
 
  
 
=== What proxy types are supported? ===
 
=== What proxy types are supported? ===
 
For authentication, the regify software supports the following authentication schemes: AUTH_BASIC, AUTH_DIGEST and AUTH_NTLM.
 
For authentication, the regify software supports the following authentication schemes: AUTH_BASIC, AUTH_DIGEST and AUTH_NTLM.
  
For automated proxy settings, the regify software is also supporting PAC files (Proxy Auto Configuration).
+
For automated proxy settings, the regify software is also supporting PAC files (Proxy Auto Configuration). This is only available on Windows and Mac.
  
 
Please always test with the most recent regify client version!
 
Please always test with the most recent regify client version!
Line 52: Line 44:
  
 
===I'm having connection problems===
 
===I'm having connection problems===
Common problems are:
+
==== Error 52 ====
* Error 58 -> No Internet connection. Check if you are connected to the Internet and if your operating system is up to date.
+
Unable to verify SSL certificate revocation lists or generic SSL related error. Mostly, the proxy server does not allow the machine to access the CRL from the SSL certificates. You may need to whitelist (see above on this page). Also, maybe some content inspection firewall is trying to intercept the SSL connection but the root certificate is not correctly installed for Windows.
* Error 59 -> Most probably you need to enter a proxy server or your proxy server credentials are invalid.
+
 
It may help you to activate the debug log (described on the product trouble-shoot page). The CURL entries are giving more information about reasons.
+
If you are using a '''proxy server on Windows''', please try to enter the proxy settings also to your IE/Edge configuration. regify is using the SSL backend of Windows and it seems that Windows needs a configured proxy to access the certificate revocation lists. As Windows is using IE configuration, you simply may have to enter the proxy to IE/Edge, too.
 +
 
 +
If you run a '''content inspection firewall''', we suggest you to white-list the URL of your regify provider and possibly also anything to *.regify.com (eg for updates). If you really have to use the content inspection firewall, please make sure that Windows (IE/Edge) is knowing the root SSL certificate of your firewall and make sure that Windows is able to access all needed CRLs (eg enter proxy setting to IE/Edge).
  
If you find '''SEC_E_INVALID_TOKEN''' together with Error 59 or cURL error EC35 in the debug logfiles - and being on a Windows 8 or 8.1 system - there might be a problem with the certificate chain of the regify provider. We found two cases regarding the certificate (chain):
+
==== Error 58 ====
 +
No Internet connection. It is a generic connectivity issue. Check if you are connected to the Internet and if your operating system is up to date.
 +
 
 +
There was also some [[IPhone_troubleshooting#I_get_error_58_for_regify_client_or_regibox_manager|iOS specific settings issue]]. Please have a look if this applies to you.
 +
 
 +
In many cases, the same help applies as for error 59 (below).
 +
 
 +
==== Error 59 ====
 +
This means, the Internet did not return an expected result. It may be a missing Internet connectivity or also some firewall/proxy that responds with some error message. Before contacting regify support, please make sure you validated the following options:
 +
 
 +
* '''Does the user need a proxy server?''' If yes, it has to be entered!
 +
** If there is a proxy and it still does not work, maybe the administrator needs to white-list the regify domains? Take a look above to find the needed ports and domains for white-listing.
 +
* '''Is the Internet connection established and working fine?'''
 +
** WLAN or network cable connected?
 +
** Does the web-browser work?
 +
* '''Is there Anti-Virus software oder a local firewall active?'''
 +
** Make sure it does not block the regify software from the Internet!
 +
** If it does, please allow Internet access to the regify software! We don't know all software, so we can't help you on this topic.
 +
* '''Mobile:'''
 +
** Is mobile data plan activated? WLAN turned on?
 +
** Is the regify application allowed to access the Internet? Maybe you allowed regify only to access Internet while connected in a WLAN?
 +
 
 +
It may help you to activate the debug log (described on the product trouble-shoot page). Especially the CURL entries from our desktop software (Windows, Mac, Linux) are giving more information about connectivity issues.
 +
 
 +
If you find '''SEC_E_INVALID_TOKEN''' together with Error 59 in the debug log-files - and being on a Windows 8 or higher system - there might be a problem with the certificate chain of the regify provider. We found two cases regarding the certificate (chain):
 
# The domain certificate was signed using SHA1. Modern Windows does no longer accept SHA1 domain signatures. As a regify provider, please ask your certificate issuer to renew your certificate by using SHA256.
 
# The domain certificate was signed using SHA1. Modern Windows does no longer accept SHA1 domain signatures. As a regify provider, please ask your certificate issuer to renew your certificate by using SHA256.
 
# The root CA certificate of the chain was signed with less than 2048 bits. Modern Windows and Mozilla does no longer accept root CA's with less than 2048 bits. Try to import the certificates without the root certificate to let the regify appliance choose the root CA. If you can't get it to work, as a regify provider, please ask your certificate issuer for support.
 
# The root CA certificate of the chain was signed with less than 2048 bits. Modern Windows and Mozilla does no longer accept root CA's with less than 2048 bits. Try to import the certificates without the root certificate to let the regify appliance choose the root CA. If you can't get it to work, as a regify provider, please ask your certificate issuer for support.
 
As a customer, please ask the support of your regify provider to update the certificates.
 
As a customer, please ask the support of your regify provider to update the certificates.
 +
 +
===I still have problems===
 +
If the problem is tagged to be SSL related (eg server certificate failure, impossible to verify CRL with error 52 etc), you may use the development environment variable RF_IGNORESSL to be > 0. This will prevent regify software from verifying SSL connection certificate validity. It still uses SSL certificate to secure the https connection, but CRL and hostname will not get verified any more.
 +
 +
We do not suggest to use this option permanently. It is meant for debugging or testing purposes.

Latest revision as of 15:12, 24 February 2021

The information on this page belongs to the following regify products:

  • regify client (Windows, MacOS, Linux)
  • regibox manager (Windows, MacOS, Linux)
  • regibill desktop
  • regipay desktop
  • regimail desktop

This also applies to the

  • regify Outlook AddIn
  • Mozilla Thunderbird AddIn
  • Lotus Notes AddIn (Templates)

The AddIn's functionality is based on the regify client and therefore the same information applies.



General connectivity information

What ports is regify using?

In order to allow regify to work, you need to allow regify to access the Internet on TCP/IP ports 443 and 80.

What domains do I need to white-list for regify usage?

Try this tool to get all domains that need to be white-listed for regify usage:
regify tool to determine domains for regify usage

This only applies if you are using a proxy-server that blocks Internet access to all sites that are not white-listed. In general, using regify behind such a restricted proxy is not very comfortable. This is because

  1. The networked regify system is a multi-provider system with many regify providers behind several Internet domains. Thus, the domains to white-list may vary.
  2. The regify providers Internet domains are secured by SSL and the regify client software is checking the SSL certificates for security reasons. Thus, the Certificate Revocation Lists (CRL) of the SSL certificates need to be white-listed, too. Some better proxy servers are able to white-list CRL domains automatically or already white-listed common CRL domains by default.
  3. During initial configuration, the regify client uses the regify Provider Lookup Service (PLS) and also connects to some regify domains to check for updates. Thus, you also need to white-list *.regify.com and the corresponding CRL domains.

If you are affected by such CRL issue, your debug log (regify client, regibill, regipay) or diagnostics log (regibox) is showing entries like "Unknown error 0x80092013" or similar. In such case, mostly the log shows an error message saying that the certificate revocation list was offline or nor available.

In this case, you need to whitelist all relevant CRL locations on your proxy server. You also may have a look below about error 52.

What proxy types are supported?

For authentication, the regify software supports the following authentication schemes: AUTH_BASIC, AUTH_DIGEST and AUTH_NTLM.

For automated proxy settings, the regify software is also supporting PAC files (Proxy Auto Configuration). This is only available on Windows and Mac.

Please always test with the most recent regify client version!

General connectivity issues

I'm having connection problems

Error 52

Unable to verify SSL certificate revocation lists or generic SSL related error. Mostly, the proxy server does not allow the machine to access the CRL from the SSL certificates. You may need to whitelist (see above on this page). Also, maybe some content inspection firewall is trying to intercept the SSL connection but the root certificate is not correctly installed for Windows.

If you are using a proxy server on Windows, please try to enter the proxy settings also to your IE/Edge configuration. regify is using the SSL backend of Windows and it seems that Windows needs a configured proxy to access the certificate revocation lists. As Windows is using IE configuration, you simply may have to enter the proxy to IE/Edge, too.

If you run a content inspection firewall, we suggest you to white-list the URL of your regify provider and possibly also anything to *.regify.com (eg for updates). If you really have to use the content inspection firewall, please make sure that Windows (IE/Edge) is knowing the root SSL certificate of your firewall and make sure that Windows is able to access all needed CRLs (eg enter proxy setting to IE/Edge).

Error 58

No Internet connection. It is a generic connectivity issue. Check if you are connected to the Internet and if your operating system is up to date.

There was also some iOS specific settings issue. Please have a look if this applies to you.

In many cases, the same help applies as for error 59 (below).

Error 59

This means, the Internet did not return an expected result. It may be a missing Internet connectivity or also some firewall/proxy that responds with some error message. Before contacting regify support, please make sure you validated the following options:

  • Does the user need a proxy server? If yes, it has to be entered!
    • If there is a proxy and it still does not work, maybe the administrator needs to white-list the regify domains? Take a look above to find the needed ports and domains for white-listing.
  • Is the Internet connection established and working fine?
    • WLAN or network cable connected?
    • Does the web-browser work?
  • Is there Anti-Virus software oder a local firewall active?
    • Make sure it does not block the regify software from the Internet!
    • If it does, please allow Internet access to the regify software! We don't know all software, so we can't help you on this topic.
  • Mobile:
    • Is mobile data plan activated? WLAN turned on?
    • Is the regify application allowed to access the Internet? Maybe you allowed regify only to access Internet while connected in a WLAN?

It may help you to activate the debug log (described on the product trouble-shoot page). Especially the CURL entries from our desktop software (Windows, Mac, Linux) are giving more information about connectivity issues.

If you find SEC_E_INVALID_TOKEN together with Error 59 in the debug log-files - and being on a Windows 8 or higher system - there might be a problem with the certificate chain of the regify provider. We found two cases regarding the certificate (chain):

  1. The domain certificate was signed using SHA1. Modern Windows does no longer accept SHA1 domain signatures. As a regify provider, please ask your certificate issuer to renew your certificate by using SHA256.
  2. The root CA certificate of the chain was signed with less than 2048 bits. Modern Windows and Mozilla does no longer accept root CA's with less than 2048 bits. Try to import the certificates without the root certificate to let the regify appliance choose the root CA. If you can't get it to work, as a regify provider, please ask your certificate issuer for support.

As a customer, please ask the support of your regify provider to update the certificates.

I still have problems

If the problem is tagged to be SSL related (eg server certificate failure, impossible to verify CRL with error 52 etc), you may use the development environment variable RF_IGNORESSL to be > 0. This will prevent regify software from verifying SSL connection certificate validity. It still uses SSL certificate to secure the https connection, but CRL and hostname will not get verified any more.

We do not suggest to use this option permanently. It is meant for debugging or testing purposes.