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

9bq8SqnSPZrkO4UA-embedded-image-c42w2ww8.png


93sx4x9etvQjHbk9-embedded-image-wjwp3rea.png


JGJBW4CJjxz5EtzU-embedded-image-asfnyarr.png



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.

MDM enrollment showing an extra Install Certificate 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.

  1. 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.
  2. Go to the Intermediate Certificate Check page at https://tools.keycdn.com/ssl.
  3. Paste the contents of the SSL .crt file from your SSL provider.
  4. 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.
  5. Click the Validate button.
  6. 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.

Intermediate Certificate Check showing no chain issues detected

Intermediate Certificate Check showing chain issues detected

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.

Self-signed HTTPS certificate shown in FileWave preferences

Automated Device Enrollment can still work with this certificate state, but manual OTA enrollment may fail until the device trusts the installed root certificate.

iOS enrollment error caused by an untrusted self-signed 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

  1. Open the manual enrollment address on the device: https://your.fw.server.DNS.here:20443/ios
  2. Select Step 1 - Install Certificate.


    Step 1 Install Certificate option on the manual enrollment page
  3. Follow the device prompts to install the certificate. Tap Install through the prompts, then tap Done.
  4. 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.
  5. Go to General → About.
  6. At the bottom of About, tap Certificate Trust Settings.
  7. Under ENABLE FULL TRUST FOR ROOT CERTIFICATES, enable trust for the newly installed certificate.

iOS Certificate Trust Settings for the installed root 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:

  1. The mandatory presence of a Subject Alternative Name
  2. Presence of an OID (1.3.6.1.5.5.7.3.1) designating the use of the certificate for TLS Web Server Authentication
  3. 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 : 

1.png    2.png      manual-OID-verify-ie.png

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:

Particular interest should be paid to the following:

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: