Certificates

Certificates add a layer of security and trust between devices. Below are some articles that discuss how various certificates are used within FileWave.

Root Trusted SSL Certificate (Using and Renewing)

Description

To communicate with devices, a certificate is required.  Our recommendation is for a root-trusted SSL certificate to be implemented.  If you are currently using a self-signed certificate, we suggest moving to a trusted root certificate; wildcard certificates are supported. This article will discuss both self-signed as well as a certificate from an authority, and the process to renew the certificate.

Since Filewave v12+, the Admin console indicates when a certificate is self-signed; Preferences > Mobile tab > HTTPS Certificate Management

SS-HTTPStab


iOS 10.3+ devices can be enrolled with a self-signed certificate.  Over the Air (OTA) though will experience warnings or errors; Self Signed Certificate Errors.

Apple provide a list of certificates automatically trusted per OS and OS version: Apple Trusted Certs

Information

Root trusted SSL certificates can be purchased from a Certificate Authority (CA).  Apple provides lists of trusted root certificates: https://support.apple.com/en-gb/HT204132

CA Vendors include:

As FileWave supports wildcard certificates, if you already have a wildcard certificate this could be uploaded without additional purchase.  Wildcard certificates are indicated by a * before the domain name. e.g.

If you already have a certificate bundle but it isn’t in the .p12 format, you can use this link to convert the file - Digicert: How to convert a certificate into the appropriate format

Requirements

Obtaining an official 3rd party root trusted SSL certificate will be dependent upon the Server's current domain.  Only a domain that includes an official 'Top Level Domain' (TLD) may qualify for a root trusted SSL certificate and the root domain must be registered to purchase a certificate.  Where the Server uses an internal-only domain, it is not possible to transition to an official certificate without first changing the domain where the Server belongs.  See migration below.  Example TLD:

In the context of a Website, the root domain refers to the highest level of the hierarchy, e.g apple.com, microsoft.com, google.com

For example:

Often the term FQDN is used as a way to indicate the idea of writing the Server name along with its connected domain.  Strictly speaking, with internal private-only domains, this should be referred to as PQDN.  Not only does FileWave recommend using an FQDN, but regardless of using an FQDN or PQDN, always specify the Server name along with its connected domain name (rather than just the hostname) when setting any preferences, be that for Server, Clients, Boosters, etc.  We also discourage the use of IP in settings.

fPnvMU8nraoExauF-embedded-image-jfaazfta.png

Migration

Migration of certificates will not pose any issues as long as:

If during migration the Server's Host Name and/or Domain Name changes, all MDM devices will lose MDM communication with the FileWave Server and require re-enrolment into MDM

Case

Current Certificate

New Certificate

Result

Any certificate to any certificate (changing name)

Self-signed cert = filewave.initech.com

Root trusted cert = fw.initech.com

CHANGING THE FQDN WILL REQUIRE DEVICES TO BE ENROLLED AGAIN

Self-signed to root trusted (keeping the same name)

Self-signed cert = filewave.initech.com

Root trusted cert = filewave.initech.com

This will NOT require devices to be enrolled again

Self-signed to wildcard

Self-signed cert = filewave.initech.com

Wild Card cert = *.initech.com

This will NOT require devices to be enrolled again

Root trusted to root trusted

Root trusted cert = filewave.initech.com

Root trusted cert = filewave.initech.com

This will NOT require devices to be enrolled again

Procedure

There are 3 key steps. 

  1. Create a CSR and Key to request a certificate from a CA
  2. Create CRT files from the downloaded certificates
  3. Convert the certificate to p12 to upload to the FileWave Server

Renewing Certificates
When renewing a current expiring certificate with a CA, step 1 is not required, if your CA allows the use of previously used private keys and certificate requests.  You will however require the key in step 3. If you have not stored the key elsewhere, the key should always be accessible on your current FileWave Server in /usr/local/filewave/certs/.

If you have not stored the key safely and the Server was to break such that the key was not retrievable, the whole process would need to be repeated instead.

Certificate Expiry
Certificate expiry should be avoided. Renewing certificates should be done in advance to maintain full working order. If the certificate expires before you have a chance to renew, managed devices will not be able to connect to the FileWave Server. However, once it is renewed your devices will check back in.

Example process

For example:

Pre-requisite: OpenSSL.  Unix-based systems have this by default.  To follow this process on Windows will require an appropriate version of OpenSSL

Step 1

Create the.CSR and . KEY from OpenSSL

From a command prompt type the following:

macOS and Unix

sudo openssl req -new -newkey rsa:2048 -nodes -keyout /certificates/fw.initech.com.key -out /certificates/fw.initech.com.csr

Windows

C:\OpenSSL-Win64\bin\openssl.exe req -new -newkey rsa:2048 -nodes -keyout C:\certificates\fw.initech.com.key -out C:\certificates\fw.initech.com.csr

You will be prompted for the following:

For this example the details should be:

The Certificates folder should now show:

fw.initech.com.csr
fw.initech.com.key

The KEY should be held safely.  The CSR will need to be uploaded to the CA during the request of the certificate creation.  You should receive confirmation from the CA, regarding domain ownership and how to retrieve the generated certificate along with some general instructions.

Step 2

Create CRT files from the downloaded certificates

It is typical, that the SSL certificate will also require an intermediate certificate.  These should be readily available from the CA's website.  If required, contact the CA for details of which intermediate you will require.

Once the SSL and intermediate certificate have been downloaded, instructions can be followed to create the CRT files.  In the case of the email from AlphaSSL, only steps 1-4 should be followed.

Sample email from AlphaSSL.

Cse4GLEGUNjFnfJU-embedded-image-pbdo0c2q.png

These 2 CRT files can be copied to the Certificates folder from Step 1.

From the example:

The certificates folder should now show:

AlphaSSLCAS.crt
fw.initech.com.csr
fw.initech.com.key
purchasedcert.crt

Step 3

Convert the certificate to p12 to upload to the FileWave Server

The necessary files are now available to create the p12.  From the command line type the following:

macOS/Linux

sudo openssl pkcs12 -export -out /certificates/fw.initech.p12 -inkey /certificates/fw.initech.key -in /certificates/purchasedcert.crt -certfile /certificates/AlphaSSLCA.crt

Windows

C:\OpenSSL-Win64\bin\openssl.exe pkcs12 -export -out C:\certificates\fw.initech.com.p12 -inkey C:\certificates\fw.initech.com.key -in C:\certificates\purchasedcert.crt -certfile C:\certificates\AlphaSSLCAS.crt

The p12 certificate can be uploaded to the Server through the Admin console: Preferences > General Tab > SSL Certificate Management; you will be required to enter your password.  Once uploaded, check the 'Common Name' on the General tab matches the Server name in the Mobile Tab. For wildcard certificates, only the domain should match.

Apache web server service will automatically restart and the FileWave Server is now ready for MDM.

Command Overview

Explanation of OpenSSL command
OpenSSL pkcs12 #Create a p12 (also know as pkcs12)
-export -out /certificates/fw.initrode.us.p12 #Output location and name of p12 to upload to FileWave
-inkey /certificates/fw.initrode.us.key #Location and name of the private key file used to generate the CSR
-in /certificates/purchasedcert.crt #Location and name of the purchased certificate provided by the 3rd party supplier
-certfile /certificates/AlphaSSLCA.crt #Location and name of Intermediate certificate, (will often contain more than one cert)

537BCm4w8svYpE0m-embedded-image-jcebqeup.png

Let's Encrypt Setup for FileWave Server (Debian)

What

This Knowledge Base (KB) article covers a Debian-focused shell script that automates Let's Encrypt SSL certificate setup for a FileWave server on Debian 12/13.

The script supports two challenge methods:

Both paths handle certificate request, FileWave certificate injection, and renewal automation.

When/Why

FileWave administrators use this when they need a trusted SSL certificate for secure communication.

This documented process is for Debian 12/13. If you are a Hosted customer, FileWave can handle certificate management for you: SSL Certificate Management for Custom Domains (FileWave-Hosted Servers).

How

Prerequisites

Challenge method guidance

If TCP/80 is not available, select DNS-01 (Cloudflare) during install.

Install steps

  1. Download the script with wget:

    wget -O filewave-letsencrypt-debian.sh https://kb.filewave.com/attachments/413

  2. Make it executable:

    chmod +x filewave-letsencrypt-debian.sh

  3. Run install:

    sudo ./filewave-letsencrypt-debian.sh --install

  4. Follow prompts for:

    • Hostname (FQDN)
    • Email
    • Validation method:
      • 1 = HTTP-01
      • 2 = DNS-01 (Cloudflare)
    • If DNS-01 is selected: Cloudflare API token

  5. Confirm values when prompted.

  6. Verify output for success messages and final summary.

What the script does

Uninstall

To remove integration files created by the script:

sudo ./filewave-letsencrypt-debian.sh --uninstall

This removes FileWave renewal hook + cron job and (if present) Cloudflare credentials file. The script intentionally leaves certbot installed.

Troubleshooting

1) FileWave server prerequisites failed

If script reports missing FileWave binaries/paths:

2) Certificate request failed (HTTP-01)

Ensure inbound TCP/80 is reachable, then retry:

sudo certbot -n --agree-tos --standalone certonly -d "<FQDN>" -m "<EMAIL>"
sudo certbot renew --force-renewal

3) Certificate request failed (DNS-01 Cloudflare)

Ensure token permissions and retry:

sudo certbot -n --agree-tos --dns-cloudflare --dns-cloudflare-credentials /etc/letsencrypt/secrets/cloudflare.ini certonly -d "<FQDN>" -m "<EMAIL>"
sudo certbot renew --force-renewal

4) FileWave UI shows old certificate behavior

If older behavior persists, verify mdm_cert_trusted is set in PostgreSQL:

image.png

/usr/local/filewave/postgresql/bin/psql -d mdm -U django

insert into ios_preferences values('mdm_cert_trusted', TRUE) on conflict (key) do nothing;

update ios_preferences set value='true' where key='mdm_cert_trusted';

\q

Let's Encrypt Setup for FileWave Server (macOS)

What

This Knowledge Base (KB) article covers the macOS FileWave Let’s Encrypt script:

The script supports two challenge methods:

Both paths handle certificate request, FileWave certificate injection, and renewal automation.

When/Why

Use this when your FileWave server runs on macOS and you need a trusted SSL certificate for secure communication.

This documented process is for macOS 14 or newer. If you are a Hosted customer, FileWave can handle certificate management for you: SSL Certificate Management for Custom Domains (FileWave-Hosted Servers).

How

Prerequisites

If TCP/80 is not available, select DNS-01 (Cloudflare) during install.

Homebrew note

The script must be launched with sudo from a normal macOS admin account (so Homebrew actions can run as the invoking user).

If Homebrew is missing, the script stops and prompts you to install Homebrew from https://brew.sh, then re-run.

Install steps

  1. Download the script with wget:

    brew install wget
wget -O filewave-letsencrypt-macos.zsh https://kb.filewave.com/attachments/498

  2. Make it executable:

    chmod +x filewave-letsencrypt-macos.zsh

  3. Run install:

    sudo ./filewave-letsencrypt-macos.zsh --install

  4. Follow prompts for:

    • Hostname (FQDN)
    • Email
    • Validation method:
      • 1 = HTTP-01
      • 2 = DNS-01 (Cloudflare)
    • If DNS-01 is selected: Cloudflare API token

  5. Confirm values when prompted.

  6. Verify output for success messages and final summary.

What the script does

Uninstall

To remove integration files created by the script:

sudo ./filewave-letsencrypt-macos.zsh --uninstall

This removes FileWave renewal hook, launch daemon/runner files, legacy cron file (if present), and Cloudflare credentials file (if present). The script intentionally leaves certbot installed.

DNS-01 Cloudflare plugin details (macOS)

If the Cloudflare plugin is missing, the script attempts installation using Certbot’s Homebrew Python environment:

$(brew --prefix certbot)/libexec/bin/python3 -m pip install certbot-dns-cloudflare

Manual verification:

certbot plugins | grep -i cloudflare

Validation / test commands

Confirm launchd job is loaded

sudo launchctl print system/com.filewave.letsencrypt.renew

Optional forced renewal test

sudo certbot renew --force-renewal

Troubleshooting

1) FileWave server prerequisites failed

If script reports missing FileWave binaries/paths:

2) Certificate request failed (HTTP-01)

Ensure inbound TCP/80 is reachable, then retry:

sudo certbot -n --agree-tos --standalone certonly -d "<FQDN>" -m "<EMAIL>"
sudo certbot renew --force-renewal

3) Certificate request failed (DNS-01 Cloudflare)

Ensure token permissions and retry:

sudo certbot -n --agree-tos --dns-cloudflare --dns-cloudflare-credentials /etc/letsencrypt/secrets/cloudflare.ini certonly -d "<FQDN>" -m "<EMAIL>"
sudo certbot renew --force-renewal

4) FileWave UI shows old certificate behavior

If older behavior persists, verify mdm_cert_trusted is set in PostgreSQL:

image.png

/usr/local/filewave/postgresql/bin/psql -d mdm -U django

insert into ios_preferences values('mdm_cert_trusted', TRUE) on conflict (key) do nothing;

update ios_preferences set value='true' where key='mdm_cert_trusted';

\q

5) launchd renewal not running

APNs

MDM/DDM communication relies upon Apple's APNs cloud service.

APNs

Apple Push Notification Service

What

The following is really just for information, describing APNs.

Push Notifications are mostly designed to allow 3rd party Apps the ability to inform users through their App, e.g. messages, sounds, etc. some relevant detail.  Users control which messages are silenced or visible and how they are visible through Settings.

Developers of Apps requiring this service register their App with Apple.  This process requires an APNs token, integrated into the App’s Server.

Generation of an APNs token itself is a required action by FileWave Admins as per the other KB articles in this chapter.

For APNs to succeed, the App and 3rd party server must be able to trust Apple’s APNs Cloud Service.  Hence, Trust Stores must include Apple’s APNs Root Certificate.

APNs Certificate Update:

At times the Root Certificate used by APNs will require replacing, prior to expiry.

APNs Cert

Service

Up to Date

From Date

Expiry Date

AAA Certificate Services root certificate

Sandbox

Jan 2025

-

Dec 31 23:59:59 2028 GMT

Production

Feb 2025

-

SHA-2 Root : USERTrust RSA Certification Authority certificate

Sandbox

-

Jan 2025

Jan 18 23:59:59 2038 GMT

 

Production

-

Feb 2025

Apple will supply information when this occurs, ensuring developers of Apps and providers of 3rd party servers update their products.

FileWave Server already includes both of the above listed certificates within its Trust Store.

3rd Party Apps

The act of installing an App requiring APNs, registers that App with APNs and the device receives a Unique Device Token.

Messages pushed can include:

Both Message and Unique Device Token are sent by the App’s Server when attempting to initiate a notification.

Notifications are relayed through Apple’s APNs service.  On receipt of the notification, the device will act accordingly, e.g. display a message to user.

In essence, the message payload therefore consists of:

The App should contain the current APNs Root Certificate within its Trust Store

MDM/DDM

MDM communication also relies upon the APNs service and therefore is an example of this process, but key aspects are:

MDM APNs messages are nothing more than a request for the device to contact the MDM server.  Any commands are subsequently sent directly to the device, once the device responds back to the MDM server from this APNs request.

Since Apple are the developers of the 'mdmclient', Apple manage its Trust Store.  Apple’s list of supported Root Certificates per OS version are available from their KB:

https://support.apple.com/en-gb/103272

APNs

APNs Certificate Creation & Renewal on macOS Computers (Keychain)

Description

Apple Mobile Device Management (MDM) requires an Apple Push Notification service (APNs) certificate; renewable yearly.

APNs Expiry
If APNs certificates are allowed to expire, all MDM communication will be lost, until renewed.  Update Model will also fail until renewed.

image.png

The following guide provides the steps to create and renew an APNs certificate using macOS with Keychain app.  

APNs Topic
An APNs certificate has a unique topic, in the form of a hexadecimal string, and belongs to the Apple ID used to create the certificate.  When renewing, the topic must match to ensure devices continue to communicate with the server.  As such, not only must the same Apple ID be used when renewing an APNs certificate, but the current certificate must also be selected for renewal.

Step-By-Step Guide

Creating the Certificate Signing Request (CSR)

  1. Open Keychain Access, located in: Applications > Utilities > Keychain Access.app.

  2. Create a CSR. Keychain Access > Certificate Assistant > Request a Certificate from a Certificate Authority... 

    image.png

  3. Enter the AppleID and Server name that you are going to be associating with this certificate in the "Common Name" field.


    Common Name
    Certificate Private Key names are visible in Keychain and the Common Name is used to set the Private Key name.  Supplying the Apple ID and Server as the Common Name, ensures the Apple ID used to generate the certificate will be stored for future reference.


    image.png

  4. Select the radio button "Saved to disk" and click Continue. 

  5. Save the CSR request, ready to upload to FileWave in the next section.

    Certificate Storage
    Consider creating a secure location to store the created certificates and sub divide them using the date or year, e.g folder named: 'MDM APNs certificates 2020'.

Sign the CSR

CSR requests must be signed before uploading to Apple.  FileWave has a portal for this process, which requires an active FileWave account.

  1. Navigate to https://csr.filewave.com/ and login.
  2. Upload the previously created CSR.
  3. 'Download signed CSR' should list this uploaded and now signed CSR. 
  4. Download this newly signed CSR, ready for upload to Apple in the next section.  Again consider where this certificate is stored.

image.png

Upload the signed FileWave CSR to Apple

Creating a new Certificate

If you are renewing a certificate then jump to Renewing a Certificate

  1. Navigate to: https://identity.apple.com/pushcert/ and log in with an Apple ID.

    This Apple ID will own the certificate and is required for every renewal.  Do not use a personal Apple ID, to avoid complications if that person where to leave the business or institution.

  2. Click 'Create'.

  3. 'Accept' Apple's 'Terms of Use'.

    image.png

Renewing a Certificate
  1. Navigate to: https://identity.apple.com/pushcert/ and log in with the Apple ID used to initially create the certificate. 
  2. Confirm the Certificate to renew.
  3. Select 'Renew'.

To confirm the certificate, compare the Subject DN (Topic) and current certificate.

Clicking the 'i' button will show the certificate details, including the Topic:

image.png

Ensure this matches with the 'Current Certificate' in FileWave Admin > Preferences > Mobile > Apple Push Notification Certificate:

image.png

If the 'Topics' do not match do not continue.  If the correct certificate is not in the list on Apple's website, this is the wrong Apple ID.  If this guide was followed in creating the original certificate, the previously used Apple ID will be viewable from the certificate "Private Key".

Click 'Choose File' and browse to the signed FileWave CSR from the previous section.

Click 'Upload' and Apple will return a 'Confirmation'.

image.png

Click 'Download' and save the ".pem" file.  Again consider where this certificate is stored.

image.png

Create a ".p12" from the Signed CSR

  1. Open Keychain Access app, select login from the Keychains list and then choose 'My Certificates' tab.

    Keychain
    If imported into the System Keychain, the Private Key will not be accessible.  If 'All Items' tab is selected, private keys will not be available!

  2. Drag the downloaded PEM file into the Keychain main window.

  3. Locate the imported certificate.  It will begin with "APSP:".

  4. Click the disclosure triangle and select the expanded private key.

    Common Name and Topic
    The name of the Private Key will show the value defined as the "Common Name" from the creation of the CSR.  Where recommendation was followed, this should list the Apple ID and Server name.  Additionally the name of the Certificate is the same as the Topic.


    image.png

  5. From the 'File' menu, choose 'Export Items...'.

    image.png

  6. Export as a .p12 file.  Again consider where this certificate is stored.

  7. Click Save.

    image.png

  8. Leave the password blank.

    image.png

  9. Enter your local admin account, when prompted, allowing Keychain to export.

image.png

Uploading the Certificate into FileWave

  1. Launch the FileWave Admin and login to the FileWave server.

  2. Open the FileWave Admin Preferences.

     

    image.png

  3. Select the 'Mobile' tab.

  4. Click 'Browse' and navigate to the saved ".p12" APNs certificate.

  5. Select the exported ".p12" certificate.

  6. Click 'Upload APN Certificate/Key Pair'.

image.png

The topic should match the previous topic.  FileWave Central should warn if the topics do match before accepting the upload:

APNs Mismatch Warning.png

Click 'OK' to save and close the Preferences dialog.

That is it! FileWave may now manage Apple devices using Apple’s Push Notification Service.

APNs certificates require yearly renewals.  Through FileWave Admin > Dashboard > Alert Settings, automated emails may configured.  Consider adding 'APN for MDM'.  Note this requires the Email preferences in Admin to be configured.

Contact Apple for help

If you forgot the email tied to your Apple Push Notiifcation you may reach out to Apple for assistant

Contact Apple for help with APN

APNs

APNs Certificate Creation & Renewal on macOS Computers (XCA)

Description

Apple Mobile Device Management (MDM) requires an Apple Push Notification service (APNs) certificate; renewable yearly.

APNs Expiry
If APNs certificates are allowed to expire, all MDM communication will be lost, until renewed.  Update Model will also fail until renewed.

image.png

This guide explains how to create the Apple Push Notification Service (APNS) certificate for FileWave using an online CSR generator and the XCA certificate management tool, instead of the Apple Keychain. The Apple Keychain often causes issues with private key handling on newer macOS versions, so this method provides a more reliable alternative. You may use any online CSR generator (for example ssl.com), it does not have to be ssl.com specifically.

APNs Topic
An APNs certificate has a unique topic, in the form of a hexadecimal string, and belongs to the Apple ID used to create the certificate.  When renewing, the topic must match to ensure devices continue to communicate with the server.  As such, not only must the same Apple ID be used when renewing an APNs certificate, but the current certificate must also be selected for renewal.

Step-By-Step Guide

Prerequisites

Step 1: Generate CSR (Certificate Signing Request)

  1. Open the CSR generator at ssl.com. ( https://www.ssl.com/online-csr-and-key-generator/ )
  2. Enter the required details:
    • Common Name (CN): e.g. FileWave APNS
    • Organization (O): your company or school name
    • Organizational Unit (OU): optional, e.g. IT Department
    • Country (C): two-letter ISO code (e.g. DE)
  3. Generate the CSR and download the files:
    • CSR file (.csr)
    • Private Key (.key)

⚠️ Keep the .key file safe – you will need it later in XCA.

Step 2: Sign the CSR with FileWave

Before the CSR can be uploaded to Apple, it must be signed by FileWave.

  1. Navigate to https://csr.filewave.com/ and log in with your FileWave account.
  2. Upload the previously created .csr file.
  3. Under Download signed CSR, your uploaded CSR should now appear as signed.
  4. Download this newly signed CSR – this is the file you will upload to Apple in the next step.
  5. Store the file in a secure location.

image.png

Step 3: Upload the signed FileWave CSR to Apple

If you are renewing a certificate then jump to Renewing a Certificate

Creating a new certificate
  1. Go to the Apple Push Certificates Portal: https://identity.apple.com/pushcert/.
  2. Sign in with an Apple ID (⚠️ do not use a personal Apple ID – use a generic business or institution Apple ID for long-term use).
  3. Click Create.
  4. Accept Apple’s Terms of Use.
  5. Click Choose File and upload the signed FileWave CSR.
  6. Click Upload – Apple will confirm the request.
  7. Download the issued APNS certificate (.pem or .cer).

image.png

Renewing an existing certificate
  1. Go to https://identity.apple.com/pushcert/ and log in with the same Apple ID that owns the certificate.
  2. Locate the certificate to renew, confirm the Subject DN (Topic) matches the certificate in FileWave Admin.
  3. Click Renew.
  4. Upload the signed FileWave CSR.
  5. Download the renewed APNS certificate (.pem or .cer).

If the 'Topics' do not match do not continue.  If the correct certificate is not in the list on Apple's website, this is the wrong Apple ID.  If this guide was followed in creating the original certificate, the previously used Apple ID will be viewable from the certificate "Private Key".

To confirm the certificate, compare the Subject DN (Topic) and current certificate.

Clicking the 'i' button will show the certificate details, including the Topic:

image.png

Ensure this matches with the 'Current Certificate' in FileWave Admin > Preferences > Mobile > Apple Push Notification Certificate:

image.png

Step 4: Import and process the certificate in XCA

  1. First, download XCA for macOS: https://github.com/chris2511/xca/releases
  2. Install and start XCA.
  3. Go to Private Keys → Import and select the previously saved .key file from Step 1.
  4. Go to Certificates → Import and load the APNS certificate you downloaded from Apple (.cer/.pem).
  5. Link the certificate with the corresponding private key in XCA.
  6. Export the certificate as a PKCS #12 (.pfx) file – important: without a password.
  7. After export, rename the .pfx file to .p12 (FileWave requires the .p12 extension).

Step 5: Import the certificate into FileWave

  1. Open the FileWave Admin.
  2. Go to Preferences → Mobile.
    image.png
  3. Import the .p12 file you exported from XCA by browsing to the file and then picking to Upload.  The topic should match the previous topic.  FileWave Central should warn if the topics do match before accepting the upload.

    image.png

    image.png
  4. Save the settings by clicking OK to close the preferences dialog and verify that devices are communicating.

Step 6: Verification

APNs certificates require yearly renewals.  Through FileWave Admin > Dashboard > Alert Settings, automated emails may configured.  Consider adding 'APN for MDM'.  Note this requires the Email preferences in Admin to be configured.

Contact Apple for help

If you forgot the email tied to your Apple Push Notiifcation you may reach out to Apple for assistant

Contact Apple for help with APN

APNs

APNs Certificate Creation & Renewal on Windows Computers

Description

Apple Mobile Device Management (MDM) requires an Apple Push Notification service (APNs) certificate; renewable yearly.

APNs Expiry
If APNs certificates are allowed to expire, all MDM communication will be lost, until renewed.  Update Model will also fail until renewed.

image.png

This guide explains how to create the Apple Push Notification Service (APNS) certificate for FileWave on Windows computers using OpenSSL. You will generate a Certificate Signing Request (CSR), have it signed by FileWave, upload it to Apple, and then convert it to a format FileWave can import.

APNs Topic
An APNs certificate has a unique topic, in the form of a hexadecimal string, and belongs to the Apple ID used to create the certificate. When renewing, the topic must match to ensure devices continue to communicate with the server. As such, not only must the same Apple ID be used when renewing an APNs certificate, but the current certificate must also be selected for renewal.

Step-By-Step Guide

Prerequisites

Administrator Access
All cmd.exe commands in this guide must be run with 'Run as Administrator'.

Step 1: Generate CSR (Certificate Signing Request)

  1. Open cmd.exe as an Administrator
  2. Create a CSR by entering the following command. This will create two files on the Desktop: request.csr and privateKey.key:
"C:\Program Files\OpenSSL-Win64\bin\openssl.exe" req -out "%USERPROFILE%\Desktop\request.csr" -new -newkey rsa:2048 -nodes -keyout "%USERPROFILE%\Desktop\privateKey.key" -config "C:\Program Files\OpenSSL-Win64\bin\cnf\openssl.cnf"
  1. When prompted, enter values for the certificate fields. For Common Name, use a descriptive name like your Apple ID and server name (e.g., company@example.com - FileWave Server). This helps you identify the certificate later.

Common Name and Private Key
The Common Name you enter will be stored in the Private Key name. Using your Apple ID and server name ensures you can identify which Apple ID created this certificate in the future—important when renewing.

1 windows_cmd_csr_creation.png

Step 2: Sign the CSR with FileWave

Before the CSR can be uploaded to Apple, it must be signed by FileWave.

  1. Navigate to https://csr.filewave.com/ and log in with your FileWave account
  2. Upload the request.csr file you created in Step 1
  3. Under Download signed CSR, your uploaded CSR should now appear as signed
  4. Download this newly signed CSR – this is the file you will upload to Apple in the next step
  5. Store the file in a secure location

csr_portal.png

Step 3: Upload the signed FileWave CSR to Apple

If you are renewing a certificate, skip to Renewing an existing certificate below.

Creating a new certificate
  1. Go to the Apple Push Certificates Portal: https://identity.apple.com/pushcert/
  2. Sign in with an Apple ID (⚠️ do not use a personal Apple ID – use a generic business or institution Apple ID for long-term use)
  3. Click Create
  4. Accept Apple's Terms of Use
  5. Click Choose File and upload the signed FileWave CSR from Step 2
  6. Click Upload – Apple will confirm the request
  7. Download the issued APNS certificate (.pem or .cer) and store it securely

create_push.png

Renewing an existing certificate
  1. Go to https://identity.apple.com/pushcert/ and log in with the same Apple ID that owns the certificate
  2. Locate the certificate to renew and click the info (i) button to view certificate details, including the Topic 

    APNS renewal.003.png

  3. Compare this Topic with the 'Current Certificate' in FileWave Admin > Preferences > Mobile > Apple Push Notification Certificate 

    APNS renewal.001.png

Topic Mismatch
If the Topics do not match, do not continue. If the correct certificate is not in the list on Apple's website, you are using the wrong Apple ID. You can identify the correct Apple ID by reviewing the Private Key name from the original CSR (which should contain your Apple ID).

  1. Click Renew
  2. Upload the signed FileWave CSR from Step 2
  3. Click Upload – Apple will confirm the request 

    apns_confirmation.png

  4. Download the renewed APNS certificate (.pem or .cer) and store it securely 

    signed_csr_download.png

Step 4: Create a .p12 file from the Signed Certificate

  1. Open cmd.exe as an Administrator
  2. Create a .p12 file by entering the following command. Replace the file paths if necessary, and note that MDM_FileWave.pem is an example – use your actual downloaded certificate filename:
"C:\Program Files\OpenSSL-Win64\bin\openssl.exe" pkcs12 -export -in "%USERPROFILE%\Downloads\MDM_FileWave.pem" -inkey "%USERPROFILE%\Desktop\privateKey.key" -out "%USERPROFILE%\Desktop\push_cert.p12" -name fw-apns
  1. When prompted for the Export Password, leave it blank and press Enter 

    cerate_p12.png

Path Issues
If the command errors when creating the .p12 file, replace the %USERPROFILE% variable with the full file path (e.g., C:\Users\YourUsername\).

  1. Verify the certificate was created correctly by running:
"C:\Program Files\OpenSSL-Win64\bin\openssl.exe" pkcs12 -info -in "%USERPROFILE%\Desktop\push_cert.p12"

This will display certificate details. Confirm that the Common Name matches the value you entered in Step 1, and that the Topic matches the value from Apple.

openssl_private_key.png

Common Name and Topic
The Private Key name will display the Common Name you entered when creating the CSR. The certificate name is the same as the Topic. Both should match the certificate you created or renewed at Apple.

Step 5: Upload the certificate into FileWave

  1. Launch FileWave Admin and log in to your FileWave server
  2. Open Preferences 

    filewave_admin_prefs.png

  3. Select the Mobile tab 
  4. Click Browse and navigate to the push_cert.p12 file you created in Step 4
  5. Select the file and click Upload APN Certificate/Key Pair

APNS renewal.001.png

The topic should match the previous topic.  FileWave Central should warn if the topics do match before accepting the upload:

APNs Mismatch Warning.png

Click OK to save and close the Preferences dialog.

FileWave may now manage Apple devices using Apple's Push Notification Service.

Step 6: Verification

APNs certificates require yearly renewals. Through FileWave Admin > Dashboard > Alert Settings, you can configure automated email reminders. Consider enabling the 'APN for MDM' alert. Note: this requires Email preferences in Admin to be configured.

Contact Apple for help

If you forgot the email tied to your Apple Push Notification certificate, you may reach out to Apple for assistance:

Contact Apple for help with APN

Self-signed SSL Certificates

Self-signed SSL Certificates

Self-Signed SSL Certificates Going Forward

Using a self-signed certificate is not the recommended option and needs to be given a second thought before implementation. Having a certificate trusted by a Global Certificate Authority (CA) is not only the most recommended and most secure option but also becoming more of a requirement for a lot of processes in the tech world.

Having a certificate trusted from a CA will also make sure all of your FileWave communication is as secure and user experience as simplified as possible. If you’re FileWave server is going to be managing Chromebooks then a root trusted certificate is required, where as managing iOS devices were self-signed certs can work, you will have to manually trust the certificate during OTA enrollment for the device to communicate with FileWave.

Of course there are some use cases where a self-signed certificate makes sense such as a test or evaluation server.

FileWave Clients

When using a self-signed certificate your client devices will need this certificate to trust for proper and secure communication with FileWave.

Initial Install

If the FileWave Client has never been installed on your macOS or Windows devices then you will need to create a custom PKG/MSI. This custom package will need to be filled out with your server address, booster info, and other important data to make sure your clients connect successfully to the FileWave Server. One of those options is Server Certificate, you will need to upload your self-signed certificate into this option so that your new client devices will be trusted by the FileWave server.

xlgwN1YL4fpm8gX0-embedded-image-r8zdn3lr.png

How do you get the self-signed certificate to upload?

To get the self-signed certificate that needs to be uploaded just follow the steps below:

  1. Log into the FileWave Admin
  2. Go to FileWave Admin → Preferences
  3. While in the General Tab find the SSL Certificate Management pane
  4. Finally click the Get Current Certificate button, this will download the current SSL certificate you have in FileWave

SS-HTTPStab

iOS devices will enroll normally during DEP but, during OTA enrollment the FileWave certificate will need to be trusted manually. Please refer to the KB article linked here for more information.

Upgrade

All macOS and Windows clients on FW version 12.9.1 and below will still communicate with the FileWave server, but once upgraded to version 13 the self-signed certificate will need to be pushed to the devices. This will be done automatically when you upload the FileWave version 13 upgrade Fileset into the Filesets section the FileWave Admin.

qRZ5HX6AGqTesQl5-embedded-image-u5cks3nm.png

iOS devices will not need anything pushed out, when the FileWave server is updated. But keep in mind during OTA enrollment the FileWave certificate will need to be trusted manually. Please refer to the KB article linked here for more information.

If you need to renew your self-signed certificate please refer the KB article linked here for those steps.

FileWave Admin

If using a self-signed certificate the FileWave Admin won’t be able to verify the identity of the server. When you log into the Admin you will be prompted that the server doesn’t trust the certificate and you have the option to continue with the connection being untrusted or you can add the certificate to your trust store then connect. Also when you connect via the Web Console you will be warned that the connection is not private.

cvBEb4wbZi6HWrxe-embedded-image-9ubrq8v3.png

Oca7w0SNbyljz7qw-embedded-image-evvj0dlk.png

On macOS, certificates manually added to trust store require explicit "Trust for SSL" permission.

euN2xkhyZhb19CwO-embedded-image-1bljg340.png

tVAWMHETelwcGXmk-embedded-image-lypskqv6.png

Imaging Virtual Server

When using self-signed certificates the FileWave server will automatically transfer the certificate to a newly created IVS, but existing imaging servers will need to be pushed the certificate.

  1. Log into the FileWave Admin
  2. Go to FileWave Admin → Preferences → Imaging 
  3. Select an imaging server then the Upload Certificate button at the bottom right of the pane

yOjB4s0EuR0gkNQ3-embedded-image-1fltzwq0.png

This will send the SSL certificate to the IVS, you have to do this for any existing IVS you have attached to your FileWave server. You can check the status of the IVS to see whether or not the certificate is uploaded, by selecting the IVS and clicking the Status… button.

eYVM6NrDSN37Czpl-embedded-image-ogya4nst.pngEKgBs16rLms4gt27-embedded-image-u0jstxtp.png

Related Content

Self-signed SSL Certificates

Renew FileWave Server Self-signed Certificate

Description

For simplicity, we should recommend Renewing with an Official SSL certificate or Let's Encrypt Setup for FileWave Server (Debian)

Using a self-signed certificate is strongly discouraged for a production server.

Information

A self-signed certificate may not be trusted by devices out of the box.  Instead, the device requires a local copy to be able to trust the certificate.  Prior to FileWave 13, this has only affected Mobile devices: Renew MDM self signed SSL certificate on iOS

However, FileWave uses the certificate for additional security for non MDM communication and initial installation or upgrading to FileWave 13 from a release of 12 or lower.

Renewal though requires additional steps to ensure device communication is not lost.

Directions

The 'fwcontrol' command for creating certificates is now a 2 step process, where 'fqdn' should be the Fully Qualified Domain Name of your FileWave Server, e.g. demo.filewave.ch:

sudo fwcontrol server generateSelfSignedCert --create --cn=fqdn [--country COUNTRY] [--state STATE] [--locality LOCALITY] [--organization ORGANIZATION] [--ou ORGANIZATIONAL_UNIT] [--email EMAIL] [--ignore_name_mismatch]
sudo fwcontrol server generateSelfSignedCert --install

Bracketed options are not required, but may be specified.

Step 1

Certificate Generation

Using demo.filewave.ch as an example:

sudo fwcontrol server generateSelfSignedCert --create --cn=demo.filewave.ch. --country Switzerland

This first step generates a new certificate, but unlike before, it does not overwrite the current active certificate.  Instead, this certificate is in a 'pending' state.  You should see the following warning when creating the certificate:

WARNING: Self-signed certificates are NOT recommended! If you install one, clients in version 13 or greater will no longer allow connections with the FileWave Server unless you put the new self-signed certificate in their trust store.
A self-signed certificate has been successfully created and is now pending for later installation on the server.

IMPORTANT!
- Before installing it, you must deploy it to the trust store of any device whose FileWave Client is in version 13 or greater, otherwise these clients will no longer be able to connect to the server!
To do so, you can create a fileset with a copy of /usr/local/filewave/certs/server.crt.pending to be deployed in the trust store folder.
- Once you are ready to install the new self-signed certificate and if you understand the risks, please run this command again with option --install.
running restart apache command

Instead a new certificate key/crt pair of files may be seen in the following server folder and will show as 'pending', along with the original key/crt pair:

/usr/local/filewave/certs/server.crt
/usr/local/filewave/certs/server.crt.pending
/usr/local/filewave/certs/server.key
/usr/local/filewave/certs/server.key.pending

As indicated by the Important message, all clients will require a copy of this certificate to communicate with the server.  During transition, it is important that both original and new certificate are installed on devices.  Copy the server.crt.pending and rename appropriately for deployment. e.g. server.2019.04.30.crt

Mobile Devices

Installing the new certificate on Mobile devices is as before, except a profile needs to be made with this new certificate as well as the current certificate:

Renew MDM self signed SSL certificate with iOS devices

Computers

Installing the new certificate on Computers is the same as the process for Upgrading to FileWave 13, but this new certificate needs to be added to a Fileset manually.  This could either be the current FileWave Upgrade Fileset or a new Fileset.  Location of the file is either:

macOS:

macOS Client/Booster Trust Store
/private/var/FileWave/trust_store

Windows:

Windows Client/Booster Trust Store
C:\ProgramData\FileWave\FWClient\trust_store

Set the certificate 'Verification' to 'Ignore At Verify' to ensure it is never removed

If the new certificate should become live on the server prior to the clients receiving this Fileset, those devices will no longer be manageable through FileWave and a manual process will be required to locally instal the certificate.

Whichever option is chosen, a method should be designed to monitor the installation process.  Only once all devices are updated, should the 'pending' certificate become the active server certificate.

Options for monitoring could include:

A Custom Field could take the following form (assuming the example file name of 'server.2019.04.30.crt'):

macOS Example Custom Field
#!/bin/bash

server_cert=$(find /var/FileWave/trust_store -name "server.*.crt")

if [[ "$server_cert" != "" ]]
then
    echo Yes
else
    echo No
fi

exit 0

Step 2

This second step enables the 'pending' certificate as the active certificate, replacing the original server certificate file.

sudo fwcontrol server generateSelfSignedCert --install

Once all clients have the new certificate within their respective trust stores, the 'pending' server certificate may now become active.  When this update of the certificate occurs, any other elements requiring the server certificate should also be updated as this time.

DEP

 The server certificate is stored as an 'Anchor certificate' within any created DEP profile.  As with any certificate change, once the certificate is renewed, new DEP profiles should be created; do not duplicate.

Custom PKG/MSI

The Custom Client Installer also needs to include the certificate.  The following links allow for uploading the current server certificate within the 'Options'

Details highlighted on: Self-Signed Certificates Going Forward

Self-signed SSL Certificates

Renew MDM self signed SSL certificate with iOS devices

Self Signed certificate renewal


Renewing MDM self-signed certificate can be done if the current certificate has to be changed:

The main issue with self-signed certificate is that, by definition, those certificates are not issued by a trusted Certificate Authority (CA), and are not trusted by default on devices. To have devices trust those certificates, the certificate must be added to the trust store. This can be achieved by:

In production environment, it is highly recommended to use trusted CA issued certificate ; self-signed certificates should only be used for testing and evaluation purpose. The best and most simple way to solve self-signed certificate renewal issues is to stop using self-signed certificate and use trusted CA certificates. There are free options like Let's Encrypt to have a trusted cert.

Planned renewal

In case you need to renew a self-signed certificate, you need to ensure all your devices will trust the new certificate before you renew it ; this implies the following steps:

  1. Create a new private key and certificate
$ openssl req -x509 -nodes -sha256 -days 3650 -newkey rsa:2048 -keyout /tmp/server.key -out /tmp/server.crt
Generating a 2048 bit RSA private key
...........................................................+++
....................+++
writing new private key to 'server.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) []:
State or Province Name (full name) []:
Locality Name (eg, city) []:
Organization Name (eg, company) []:
Organizational Unit Name (eg, section) []:
Common Name (eg, fully qualified host name) []:filewave.acme.org
Email Address []:

2. Import server.crt file into a profile fileset

jMRHI8nEJ5Ig9Ghr-embedded-image-g89p3kaa.png

3. Deploy the profile filest to all your devices

4. You are able to confirm that the profile was received and trusted by the device by going to Settings → General → About → Certificate Trust Settings, and should see your old as well as new self-signed certificate listed and trusted. The screen shot below shows what you will see with the device trusting both certificates. 

5Di1Xo4PrLTX4QcZ-embedded-image-nfve1ej2.png

5. Once all devices have the profile, you can switch the key and certificate. The path to your new "server.crt" and "server.key" may change depending on where the certificate is located on your FileWave server:

$ cd /usr/local/filewave/certs
$ mkdir old_certs
$ mv server.crt server.key old_certs
$ cp /tmp/server.*
$ fwcontrol apache restart

6. Re-create DEP profiles and associations as the DEP profile contains a copy of the certificate and is sent to Apple at association time ; a new certificate implies a new DEP profile.

Failure to update your DEP profiles to have the new profile will cause trust issues at enrollment

Unplanned or late renewal

Worst case possibility using a self-signed cert that expires.

If the current certificate is not trusted by devices anymore (or because some devices did not get the new certificate before the switch), the renewal process remains the same, but with one exception: as devices will stop trusting the server certificate it's not possible to use FileWave to deploy the new certificate.

At this point, the best solution is to move forward with a trusted CA certificate ; your devices will start communicating immediately to your server as soon as the certificate is in place.

In case trusted CA is not possible, you will have to manually add the certificate to each impacted device:

  1. deploy the new certificate to devices ; you can either send it via e-mail, or send your users to the usual enrollment page and ask them to install the cert via "step 1"
  2. in the trust store, the newly installed certificate must be granted "use for SSL" permission

Related Content

Troubleshooting

Troubleshooting

Export .p12 SSL Certificate from Windows

When managing mobile devices, it is considered best practice to install a root trusted SSL certificate on the FileWave Server. This certificate is located in the FileWave Admin > Preferences > Mobile tab. If you generated the Certificate Signing Request (CSR) for your SSL certificate on a Windows based system and have completed the certificate generation process, the SSL certificate and intermediates bundle can be exported as a .pfx file directly from Windows. This bundle would contain all components (private key, public certificate, Root CA certificate, and intermediate certificate bundle). This .pfx file (after renaming the extension to .p12) can then be uploaded to the FileWave Admin > Preferences > Mobile tab without any modification.

Step-by-step guide

9bq8SqnSPZrkO4UA-embedded-image-c42w2ww8.png


93sx4x9etvQjHbk9-embedded-image-wjwp3rea.png


JGJBW4CJjxz5EtzU-embedded-image-asfnyarr.png



Troubleshooting

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

Troubleshooting

Self Signed Certificate Error during iOS OTA Enrollment

This article shows how to resolve an error if you are manually enrolling 10.3+ devices in FileWave with a self-signed certificate.

It is considered a best practise to have a root trusted certificate defined in the FileWave> Preferences> Mobile>  HTTPS certificate section. In FileWave v12+ it is easy to determine whether you have a self-signed certificate or not. Simply log into the FileWave Admin, open the preferences, go to the "Mobile" tab, and you will see in the HTTPS section, the following line:

SS-HTTPStab

If this is the case, you will still be able to enroll iOS 10.3+ devices through DEP. But if the device is iOS 10.3+ and you try a manual web enrollment (OTA), you will get the following error. 

SS-Error

If you choose to retain your self-signed certificate, you will have to use the steps below to resolve the error. Alternatively, you can purchase a root trusted certificate, and you will not encounter this issue. Again, it is highly recommended that you purchase a root trusted certificate (can include a wildcard) so that you don't have to work around this trust issue, as described below. 

Steps to Resolve (if you choose to keep a self signed certificate in place)

  1. Navigate to the your manual enrollment address: https://your.fw.server.DNS.here:20443/ios
  2. Select: "Step 1 - Install Certificate"


    SS-Step1
  3. Once you have selected step one, the device will ask you to Install the cert, go through those three prompts by hitting Install each time and finally Done.
  4. After the certificate has been installed, open the "Settings" app on the iOS device. Do not start Step 2 (This will prompt the error). 
  5. Go into General => About
  6. At the bottom of the "About" section, tap the sub section called "Certificate Trust Settings"
  7. You will see an option called ENABLE FULL TRUST FOR ROOT CERTIFICATES
  8. Toggle that option for your newly installed certificate

SS-TrustCert

Now go back to the manual enrollment page and finish the steps with "Step 2 - Enroll Device".

Troubleshooting

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: