Avalanche 6.X and Certificates

Version 16

    Verified Product Versions

    Avalanche 6.1Avalanche 6.0Avalanche 6.2

     

    Scenario:

     

    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

     

     

     

    Environment: iOS

     

    For secure communication for iOS devices, please see the following articles Please ntoe that Avalanche 6.2 has deprecated DEP and VPP for iOS:

     

    Environment: Android

     

    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)
    • Self-Signed

     

    Third Party Certs

     

    More information on how certificates are structured What a Third Party Certificate Should Look Like

     

    Third Party Signed certs for Android should be generated as a fully bundled certificate that includes the entire chain of trust.

    certpath.png

     

    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)

     

     

    Avalanche 6.2 - How To Import Certificates into IIS

     

    Avalanche 6.2 - How to Export completed cert from IIS for Avalanche:

    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.

     

     

    It should be pointed out that as of 6.1.0.127 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:

    1. 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
    2. 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
    3. 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: [0] Cert Type: X.509, Public Key Algorithm: RSA, Format: X.509 
    2018-04-04 12:02:35,986 INFO  WebServerSelfCheck        263   [d=] - WebServerSelfCheck: [0] 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: [0] 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: [0] X509 subject alt names: [*.ld.landesk.com, ld.landesk.com] 
    2018-04-04 12:02:35,986 INFO  WebServerSelfCheck        285   [d=] - WebServerSelfCheck: [0] 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: [1] Cert Type: X.509, Public Key Algorithm: RSA, Format: X.509 
    2018-04-04 12:02:36,002 INFO  WebServerSelfCheck        263   [d=] - WebServerSelfCheck: [1] 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: [1] 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: [1] 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: [2] Cert Type: X.509, Public Key Algorithm: RSA, Format: X.509 
    2018-04-04 12:02:36,002 INFO  WebServerSelfCheck        263   [d=] - WebServerSelfCheck: [2] 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: [2] 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: [2] 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 Certificates:

    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!