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?
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 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.
- 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.
Automatically determine needed locations
Manually getting all needed domains to white-list:
- In general, regify needs access to all *.regify.com domains. This is for using the PLS (Provider Lookup Service) and for automatic updates etc.
- 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.
- 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
- 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?
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).
Please always test with the most recent regify client version!
General connectivity issues
I'm having connection problems
Common problems are:
- Error 52 -> Unable to verify SSL certificate revocation lists. Mostly, the proxy server does not allow the machine to access the CRL from the SSL certificates.
- Error 58 -> No Internet connection. Check if you are connected to the Internet and if your operating system is up to date.
- 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 find SEC_E_INVALID_TOKEN together with Error 59 in the debug logfiles - 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 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.
This is only available from regify Client V4.2, regibox Manager V1.4 and regify Desktop V2.0 or higher (mid 2016).