Avalanche 6.x requires an SSL certificate for secure communication for all styles of Smart Devices. This document is designed as a quick reference guide as well as general data repository for details on certificates. This will be a living document that will get updated frequently with relevant data. You can also find valuable information within our help documentation: Enabling Secure Communication
For secure communication for iOS devices, please see the following articles Please ntoe that Avalanche 6.2 has deprecated DEP and VPP for iOS:
- iOS Apple Push Notification Service (APNS)
- Apple DEP configuration
- How to enroll an iOS device when using a self signed cert
Android devices are much easier to setup and use. This is due to a more robust environment provided by Android
- Third party signed (preferred for security and ease of use)
Third Party Certs
More information on how certificates are structured What a Third Party Certificate Should Look Like
Where to add certificates on Avalanche 6.2 https configuration for Android devices missing on avalanche 6.2/Where to add the SSL certificate on avalanche 6.2
Third Party Signed certs for Android should be generated as a fully bundled certificate that includes the entire chain of trust.
Within this certification path we can see the cert path from our domain all the way to the Cert Authority.
If you have multiple layers of Certificate Authorities, PLEASE ENSURE YOU ALWAYS INCLUDE ANY INTERMEDIATE LEVEL CERTIFICATES AS YOUR ANDROID DEVICE WILL NOT KNOW HOW TO ADD THE MISSING LEVEL.
Avalanche will support PFX/P12 certs. PFX certs were designed as a Microsoft Extension whereas the P12 was designed for Netscape. Previously these certs were extremely different but with modern versions of these certs they have become identical, meaning they will work the same way.
If you have concerns about one cert type or another you should be able to rename the file extension and the certificate will work the same.
PLEASE BE AWARE: Ivanti does not have a preferred CA. Though it should be pointed out some CA’s have easier Cert tools than others.
Creating a CSR
The first step to generating a certificate for your Avalanche Environment is to generate a CSR file a CSR is a Certificate Signing Request. The CSR will be generated from the server it is being requested for. This system must be accessible by your Chosen Certificate Authority. This certificate can either be for a single server or multiple servers. No matter which style of certificate you are requesting the Certificate Authority (such as Digicert) must be able to communicate to the server address.
For information on building the certificate in IIS please watch the video below (which was created by Digicert). We have created an article ontop of the video to provide a step by step method to do it as well: Avalanche 6.2 - Using IIS 7 / 8 / 8.5 / 10 to a make a CSR Request
Combining and Exporting Certificates (missing intermediate cert)
Private Key is Missing
Occasionally we will see that a certificate is missing its private key.. this means that a private key was not created at the same time as the CSR. this article will walk you through associating the private key to a certificate
Adding certificate to Avalanche
Self Signed Certs
We have multiple methods to assist with creating a self-signed cert. It must be pointed out that a self-signed cert will have limitations when it comes to replacing the certificate. Because the keys will be different from self-signed to self-signed you will need to re-enroll a device when it is about to expire. This will be a manual process requiring someone to touch each device to re-register. You will also be required to use a pin code or pattern lock screen on each of the devices. Finally, you will be unable to use the bulk enrollment feature.
- Creating a self-signed cert: Avalanche 6.X Smart Device Certificate Utility
- Adding Self-Signed certificate to Avalanche: How to Enroll your Android Device on Avalanche On Premise
It should be pointed out that as of 220.127.116.11 enabler for android we have began increasing the security of the Avalanche Android Enabler. This means we have become more strict in how we work with certs and you can see issues in your environment that were not previously there. This is only seen with self signed certs.
We will provide a certificate troubleshooting guide at a later time
Common Issues with certs
The following lines are pulled from the SDS log files.. These are general issues that we run into quite often:
- E com.wavelink.android.ans.AbstractPrioritizedANSSocketThread: Failed getting socket stream for host FQDN, Reason:com.android.org.bouncycastle.jce.exception.ExtCertPathValidatorException: Could not validate certificate: Certificate not valid until Mon Feb 13 00:00:00 GMT+00:00 2017 (compared to Sun Jan 22 19:41:23 GMT+00:00 2017)
- The device must have a date within the valid window of the certificate
- Unable to resolve host "FQDN": No address associated with hostname:Unable to resolve host "FQDN": No address associated with hostname
- This is resolved by adding a Subject Alternate Name
- also has been resolved by updating server.crt Install Cert Failed
- E/com.wavelink.android.webservices.TransportThread(1607): 2014-09-11 21:10:22.96 No peer certificate
- Cert does not contain full chain
- also has been resolved by updating server.crt Install Cert Failed
4. With the release of 6.2 we have improved the logging and alerts for certificates within the Avalanche Environment. Every time the SDS service is started or a certificate is imported an automated validation of the tool will begin. It will look something similar to this:
2018-04-04 12:02:35,986 INFO WebServerSelfCheck 244 [d=] - WebServerSelfCheck: Cipher Suite: 2018-04-04 12:02:35,986 INFO WebServerSelfCheck 252 [d=] - WebServerSelfCheck:  Cert Type: X.509, Public Key Algorithm: RSA, Format: X.509 2018-04-04 12:02:35,986 INFO WebServerSelfCheck 263 [d=] - WebServerSelfCheck:  X509 Subject: CN=*.ld.landesk.com, O=LANDesk Software Inc, L=South Jordan, ST=Utah, C=US 2018-04-04 12:02:35,986 INFO WebServerSelfCheck 271 [d=] - WebServerSelfCheck:  X509 Issuer: CN=DigiCert SHA2 High Assurance Server CA, OU=www.digicert.com, O=DigiCert Inc, C=US 2018-04-04 12:02:35,986 INFO WebServerSelfCheck 277 [d=] - WebServerSelfCheck:  X509 subject alt names: [*.ld.landesk.com, ld.landesk.com] 2018-04-04 12:02:35,986 INFO WebServerSelfCheck 285 [d=] - WebServerSelfCheck:  Valid between 2015-10-19 18:00 and 2018-10-24 06:00 2018-04-04 12:02:35,986 INFO WebServerSelfCheck 252 [d=] - WebServerSelfCheck:  Cert Type: X.509, Public Key Algorithm: RSA, Format: X.509 2018-04-04 12:02:36,002 INFO WebServerSelfCheck 263 [d=] - WebServerSelfCheck:  X509 Subject: CN=DigiCert SHA2 High Assurance Server CA, OU=www.digicert.com, O=DigiCert Inc, C=US 2018-04-04 12:02:36,002 INFO WebServerSelfCheck 271 [d=] - WebServerSelfCheck:  X509 Issuer: CN=DigiCert High Assurance EV Root CA, OU=www.digicert.com, O=DigiCert Inc, C=US 2018-04-04 12:02:36,002 INFO WebServerSelfCheck 285 [d=] - WebServerSelfCheck:  Valid between 2013-10-22 06:00 and 2028-10-22 06:00 2018-04-04 12:02:36,002 INFO WebServerSelfCheck 252 [d=] - WebServerSelfCheck:  Cert Type: X.509, Public Key Algorithm: RSA, Format: X.509 2018-04-04 12:02:36,002 INFO WebServerSelfCheck 263 [d=] - WebServerSelfCheck:  X509 Subject: CN=DigiCert High Assurance EV Root CA, OU=www.digicert.com, O=DigiCert Inc, C=US 2018-04-04 12:02:36,002 INFO WebServerSelfCheck 271 [d=] - WebServerSelfCheck:  X509 Issuer: CN=DigiCert High Assurance EV Root CA, OU=www.digicert.com, O=DigiCert Inc, C=US 2018-04-04 12:02:36,002 INFO WebServerSelfCheck 285 [d=] - WebServerSelfCheck:  Valid between 2006-11-09 17:00 and 2031-11-09 17:00 2018-04-04 12:02:36,002 DEBUG WebServerSelfCheck 129 [d=] - WebServerSelfCheck: Exit status: OK
Depending on if your certificate is good or bad it will output a message of OK or generate a string with the issue.
A bad certificate will display the following:
2018-10-01 15:02:09,993 DEBUG WebServerSelfCheck 86 [d=] - WebServerSelfCheck: running 2018-10-01 15:02:09,993 DEBUG WebServerSelfCheck 170 [d=] - WebServerSelfCheck: Testing trusted SSL certificate, subject 'CN=*.ld.landesk.com, OU=Support, O="Ivanti, Inc.", L=South Jordan, ST=Utah, C=US', public addr 'wl-bs-sds.ld.landesk.com' 2018-10-01 15:02:09,993 DEBUG WebServerSelfCheck 182 [d=] - WebServerSelfCheck: Using URL https://wl-bs-sds.ld.landesk.com:443 2018-10-01 15:02:10,009 ERROR WebServerSelfCheck 203 [d=] - WebServerSelfCheck: handshake error javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target 2018-10-01 15:02:10,009 DEBUG WebServerSelfCheck 129 [d=] - WebServerSelfCheck: Exit status: HANDSHAKE_FAILURE
This can be resolved by following this article:Smart Device Failing to Communicate: SDS Log Shows PKIX path building failed
Splashtop Center accepts PFX (Personal Information Exchange) format for SSL certificates.
Just like the SDS you must have a full chain of trust and have a password for your certificate.
More information to come!