Troubleshooting

Export .p12 SSL Certificate from Windows
When managing mobile devices, install a trusted SSL certificate on the FileWave Server. The server SSL certificate is configured in FileWave Central > Preferences > Mobile. If you generated the Certificate Signing Request (CSR) on a Windows-based system and completed the certificate generation process, Windows can export the SSL certificate and intermediate bundle as a .pfx file. That bundle should include the private key, public certificate, Root CA certificate, and intermediate certificate bundle. Rename the .pfx file to .p12, then upload it in FileWave Central > Preferences > Mobile without modifying the certificate contents.
Step-by-step guide
Open a Run dialog and enter "mmc".
Go to File > Add/Remove Snap-in.
Add the Certificates snap-in and click the Add > button in the middle.
Choose Computer account.
Pick Local computer and click Finish.
Click the OK button.
In the MMC console browse to Certificates (Local Computer) > Personal > Certificates on the left. If your certificate is not there, browse the rest of the Certificates (Local Computer) tree until you find it.
Select your certificate in the middle pane, right-click, and pick All Tasks > Export.
When prompted, pick Yes, export the private key.
Under Personal Information Exchange - PKCS #12 (.PFX), check Include all certificates in the certification path if possible. Leave the other two checkboxes unchecked.
Click the Next button and specify an export password. FileWave Central will prompt for this password when you upload the SSL certificate in Preferences > Mobile.
Save the file to your desktop.
Change the file extension from .pfx to .p12.
Upload the .p12 file in the Mobile preferences tab of FileWave Central.

Determine Correct Intermediates Bundle for SSL Certificate
Some SSL providers include multiple intermediate certificate bundles with your SSL certificate. Your SSL certificate must be merged with the correct intermediate bundle and your private key to generate the .p12 certificate file uploaded in the Mobile preferences tab of FileWave Admin. If the wrong intermediate bundle is used, interactive MDM enrollment may show an extra certificate-install step before Enroll Device, and client devices may not be able to communicate with the FileWave MDM server correctly. A healthy trust chain normally shows only the Enroll Device step.
Step-by-step guide
Follow the steps below to determine the correct intermediates bundle to pair with your SSL certificate so that only one step appears on the interactive enrollment page.
When downloading your SSL certificate from your provider, choose Apache format if that option is available. If the certificate files do not have a .crt extension, download them again in Apache format.
Go to the Intermediate Certificate Check page at https://tools.keycdn.com/ssl.
Paste the contents of the SSL .crt file from your SSL provider.
Paste the contents of the intermediate .crt bundle directly below it. The intermediate bundle may contain multiple certificates; include the full bundle below your SSL certificate.
Click the Validate button.
The checker returns either No chain issues detected or Chain issues detected. If chain issues are detected, repeat the check with the next intermediate bundle from your provider. Use the intermediate bundle that returns no chain issues when generating the .p12 file for FileWave.

Self Signed Certificate Error during iOS OTA Enrollment
This article shows how to resolve the certificate-trust error that can appear when you manually enroll iOS or iPadOS devices through OTA enrollment while the FileWave Server uses a self-signed certificate.
For production environments, use a publicly trusted server certificate when possible. If the server still uses a self-signed certificate, confirm the certificate shown in FileWave Central → Preferences → Mobile → HTTPS certificate.
Automated Device Enrollment can still work with this certificate state, but manual OTA enrollment may fail until the device trusts the installed root certificate.
If you keep the self-signed certificate, use the steps below on the device before starting the enrollment step. Replacing the self-signed certificate with a publicly trusted certificate avoids this manual trust workflow.
Steps to resolve when keeping a self-signed certificate
Open the manual enrollment address on the device: https://your.fw.server.DNS.here:20443/ios
Select Step 1 - Install Certificate.
Follow the device prompts to install the certificate. Tap Install through the prompts, then tap Done.
After the certificate is installed, open the Settings app. Do not start Step 2 - Enroll Device yet, because the device has not trusted the certificate.
Go to General → About.
At the bottom of About, tap Certificate Trust Settings.
Under ENABLE FULL TRUST FOR ROOT CERTIFICATES, enable trust for the newly installed certificate.
Return to the manual enrollment page and continue with Step 2 - Enroll Device.

SSL Server Certificates - iOS 13 and macOS 10.15
Apple have updated their requirements for certificates for their new operating system releases:  https://support.apple.com/en-us/103769
The new requirements can be broken down in the 3 major sections:
The mandatory presence of a Subject Alternative Name
Presence of an OID (1.3.6.1.5.5.7.3.1) designating the use of the certificate for TLS Web Server Authentication
Maximum validity period of 825 days
Requirement 1 is confirmed to render MDM clients unable to connect to the MDM server when not being met. 
Requirements 2 and 3 are not currently ( as of 24th of September 2019 ) interfering with MDM function when not being met. These two new requirements are not met by newly generated self-signed certificates as of FileWave Server 13.1.3 - so renewing your self-signed certificate will not mitigate this issue permanently. FileWave Server will be updated in a future release to accommodate these new guidelines in order to comply with self-signed certificates. 
If you are using a self-signed certificate on a production server we recommend you purchase a valid 3rdparty certificate that has been signed by a trusted root CA. 
To verify whether your certificate is affected by a missing subject alternative Name, please run the following command on your Linux/macOS server : 
certSANCheck=$(openssl x509 -in /usr/local/filewave/certs/server.crt -text -noout | awk '/DNS/'; ); if [[ "$certSANCheck" == "" ]]; then echo "Certificate requires updating"; else echo "Certificate has SAN, no action required"; fi
If the above script returns "Certificate has SAN , no action required" , please verify the presence of the OID extension using the next snippet . Otherwise, please jump to "Directions" below to read on for instructions on how to mitigate this issue. 
certOIDCheck=$(openssl x509 -in /usr/local/filewave/certs/server.crt -text -noout | awk '/TLS Web Server Authentication/'; ); if [[ "$certOIDCheck" == "" ]]; then echo "Certificate requires updating"; else echo "Certificate has OID, no action required"; fi
If the above script returns "Certificate has OID , no action required" , you can stop reading now . Otherwise, please check this page for updates on how to mitigate this issue .
To verify a Windows Server based Installation, please browse to your iOS enrollment page and verify the certificate as shown below : 
    
      
If the above "Subject Alternative Name" is visible in the Certificate Details, and the "Enhanced Key usage" shows the OID 1.3.6.1.5.5.7.3.1, you can stop reading now. Otherwise, please read on for instructions on how to mitigate this issue. 
Description
Apple have updated their requirements for certificates for their new operating system releases:
https://support.apple.com/en-us/103769
Some of these restrictions were in place with earlier versions of iOS and macOS:
https://support.apple.com/en-gb/100758
Loss of Device Management
This could affect device communication if using non-compliant certificates. Certificate should be updated as per the following guide before updating devices or MDM device management will be lost.
Self-Signed and 3rd Party Certificates
Although this is likely to be an issue with older self-signed certificates, official 3rd party certificates could also be affected. Where 3rd party certificates are affected, contact your supplier for an updated certificate.
Information
Requirements:
FileWave Server version 13.1.0+
Particular interest should be paid to the following:
TLS server certificates must present the DNS name of the server in the Subject Alternative Name extension of the certificate. DNS names in the CommonName of a certificate are no longer trusted.
When using self-signed certificates, if the certificate does not have a SAN entry, it will no longer be trusted in Apple's new operating systems.
FileWave has an option to generate self-signed certificates:
sudo fwcontrol mdm generateSelfSignedCert --cn=fqdn [--country COUNTRY] [--state STATE] [--locality LOCALITY] [--organization ORGANIZATION] [--ou ORGANIZATIONAL_UNIT] [--email EMAIL] [--replace] [--ignore_name_mismatch]
However, earlier versions of FileWave did not generate a certificate with a Subject Alternate Name (SAN).  
As of FileWave 13.1.0, fwcontrol generates a certificate that includes a SAN  
Certificate Generation
Although a newer version of FileWave may be in place now, what is relevant here is the version of FileWave that was running when the certificate was generated.
Directions
This is a good opportunity to switch to an official SSL certificate, using our guide to ensure device management continuity:
Root Trusted SSL Certificate (Using and Renewing)
If you cannot make the switch at this time , please observe the following KB for distribution in profiles through MDM:
Renew MDM self signed certificate
For clients, the new certificate needs be added to the client's 'Trust Store' prior to making the pending generated certificate live.  Details found on the following KB.
Renew Self-signed Certificate - FileWave 13+
Recovery
For devices upgraded when the server certificate did not meet requirements there are options:
Obtain an official SSL 3rd party certificate (highly recommended)
Manually install and trust the server certificate on each affected device
Update the self-signed certificate as per the details then re-enrol all affected devices (may involve erasure of device)