Version 7

    Public Copy: SSL, Vanity URLs, and Akamai Information Sheet



    SSL (Secure Sockets Layer) is the standard security technology for establishing an encrypted link between a web server and a browser. This link ensures that all data passed between the web server and browsers remain private and integral. SSL is an industry standard and is used by millions of websites in the protection of their online transactions with their customers.


    A Vanity URL is an alias that best represents your Jive instance for your organization. By default all Jive Hosted customers receive a default name using the domain suffix (Ex: To customize the URL we recommend that our customers place an alias on their domain that points to our default name. This document provides an overview of the process and some options available.


    Akamai is a company that has developed a global array of interconnected servers that cache content supplied by its customers and their users. This way the content is physically much closer to the user who wants to access it. Akamai is used to speed up the load time of site content when it is hosted in a far away location. This service also makes use of specialized DNS servers and high caching web servers to lower latency for end users.



    Implementation Processes


    There are two methods of implementing SSL; as of version 7, Jive only supports Forced SSL:

    • Forced SSL: All traffic is forced over HTTPS. The jiveurl system property is set to https://, the tomcat connector is configured, and a 301 redirect iRule is placed on the VIP's.
    • Login/Registration Only:  The system property <jive.auth.forceSecure=true> is added and the Jiveurl stays http://.
      • No longer supported in Jive 7+.


    The implementation process for SSL is not very complex, but it is precise and requires attention to detail from both Jive Hosting and the customer.

    1. A customer creates a case requesting their site to be configured for SSL in accordance with the SSL options specified above.
      • We recommend having your DNS Admin (or equivalent) open this case to ensure comprehension and proper follow-through.
    2. Jive responds to the case with a template to gather some required information from the customer.
    3. Once received, Jive forwards the gathered information to our hosting provider, and a CSR is generated.
    4. Jive replies to the case and provides the CSR and DNS entries that will need to be made.
    5. Customer takes the CSR from Jive and uses it to purchase a UCC certificate from a Certificate Authority (CA), then gives the certificate to Jive by attaching it to the case.
    6. Jive applies the certificate to the customer's VIPs, forces SSL if desired, changes the jiveurl, configures the tomcat connector (if forced), and restarts the site.
    7. The site is tested by Hosting and the customer to make sure everything is working as expected.


    Here is an example of the template Jive will ask you to fill out with required information in order to generate a CSR:

    QuestionCustomer Response

    Choose an option for SSL configuration:

    1. Send all traffic over HTTPS
    2. Send only logins and registrations over HTTPS
      • Not supported in Jive 7+.
    Common name (site's full domain name / Vanity URL)
    Division (e.g., IT, Marketing)
    Organization (company name)
    Locality (e.g., city name)
    State or Province (fully spelled out)
    Email address for certificate (if desired)

    If you would like a specific *vanity URL for your UAT instance please specify here.

    Otherwise, we will append uat- to your existing URL to support SSL on your UAT site.



    Vanity URL

    Implementing a Vanity URL is fairly straight forward, and can be done without the use of SSL (thought Jive 7+ require SSL be forced). There are two parts to implementation:


    Part One: DNS Entry

    You will need to decide on a Vanity URL and create a DNS entry to reflect the change. This requires a change on the customer network and should be coordinated with the department or persons responsible for managing external DNS for your organization.

      • To begin this process simply submit a case in your Customer Group on the Jive Community asking to configure a Vanity URL for your site. A Hosting engineer will provide you with the technical information required by your DNS manager to implement the change.
      • We recommend having your DNS Admin (or equivalent) open this case to ensure comprehension and proper follow-through.


    Part Two: SSL (Optional)

    See the options above.




    When Akamai is purchased, a new case will be created in your customer support group to start the implementation process, which is explained below.

    1. The case will ask you for specific details that are required for the successful implementation of Akamai.
      • No action can be taken towards the setup of Akamai until this information is supplied.
    2. Once the requested information is supplied a ticket is opened between Akamai and Jive Hosting to begin the configuration process through Akamai.
    3. Concurrently with Step 2, Jive Hosting will configure the application of your instance for Akamai.
    4. When Akamai has completed the configuration on their side they will:
      • Perform Domain Control Validation.
      • Provide Jive Hosting with information necessary for you to test your Akamai configuration on their staging network. This information is relayed to you in the case, along with details on configuring a local host for testing.
    5. Once you have completed testing, you will need to create a DNS entry and your configuration will be promoted to the Akamai production network.

    For other outlying details on Akamai, please see the More About Akamai section below.



    Important Details

    Below is a list of details that are important to acknowledge when considering adding SSL and/or a Vanity URL to a Jive Hosted instance.

    • Vanity URLs require a subdomain, such as Root domains such as '' are not supported in the Jive Hosted environment due to various limitations:
      • A root domain requires an A Record which prevents a customer from using a CDN, such as Akamai, because CDNs require a CNAME entry.
      • During a major upgrade, data center migration, or DR scenario, additional coordination would be required with the person in your org who maintains your DNS.
    • SSL certificate requests are for customer domains/Vanity URLs and can not be purchased for the domain (including variations of
      • Wildcard certificates (* are also no longer used; recent Microsoft products (.net) have a problem with them.
    • We recommend a SAN (Subject Alternate Names) certificate to support multiple names; this type of certificate is also required for maximum capability.
    • SSL needs to be set up before configuring SSO.
    • Common tasks that can cause issues with certificates which may result in purchasing additional certificates later on include, but are not limited to:
      • Changing your Jive URL
      • Adding the SharePoint Connector to your Jive Instance (this does not apply to Jive for SharePoint)
      • Adding Jive for Office or Jive for Outlook to your instance
      • Upgrading to Jive 5 or greater from a previous version of Jive
        • If you are performing a major upgrade of your instance and have SSL/SSO enabled and configured on your current instance, and want to test SSO on your new upgrade instance, there are two ways of doing so:
          • Recommended: Use the Jive wildcard certificate on your upgrade instance during the testing phase (The URL will be the Hosted URL (Ex:
          • Use your named certificate (the one applied to your current instance) and create a local host entry on all clients that will be accessing the upgrade instance (Ex:
    • As of Jive v5.0+: If a customer plans on using the Apps market functionality, they will need to purchase a "Multiple Domain UC Certificate" with SAN entries for the vanity apps domain.
      • Domain Examples:
    Vanity Domain

    Vanity Apps


    Implementation Impacts

    The following items may be impacted when you implement one of these services which causes the jiveURL property to change:

    • Single Sign On (SSO): The Base Metadata URL must match the jiveURL and can be checked and configured by Jive Support.
      • This change requires a restart, which can be performed in the Jive Cloud Admin.
    • Mobile: Mobile technically does not require for the Gateway URL to match the jiveURL, but it does require the connection settings to be updated after a jiveURL change. We recommend updating the Gateway URL to match the new jiveURL; this can be done in the Admin Console under Mobile > Connection Setup page.
    • Video: The callback URLs with our partner Twistage need to match the jiveURL; any changes will need to be updated by a member of Jive Support.
    • Gamification: The callback URL needs to match the jiveURL; any changes will need to be made by a member of Jive Support.
    • Twitter: You will need to reconfigure your Twitter plugin with a new Twitter app.  Configuration instructions are found here: Setting Up Access to Twitter.

    • LinkedIn: A new app will need to be configured by Jive Support.
    • Jive for Office/Outlook: The client-side application will need to be updated with the new URL. This action must be performed by each individual user.
    • Apache Server Check:  Any previously configured redirects will need to be reconfigured to point to the new URL by Jive Hosting.
    • Emoticons: The Emoticon Filter needs to match the jiveURL. This is configured in the Admin Console under Spaces > Settings > Filters and Macros > Emoticon Filter.
    • Content & Widget Links: Direct links in content & widgets will no longer work when the jiveURL changes. Jive Support can run a database query to redirect such links.

    Please Note: This list is not all-encompassing and does not take into consideration any customizations which may be impacted. We strongly advise customers to consult the developer of any customizations before approving this change.



    Customer DNS for SSL and Vanity URLs

    The typical SSL cert is configured with a Common Name (CN)/Vanity URL.  Jive Hosting will ask the customer to configure a CNAME record in their DNS for the CN to point to the hosted domain. Using the Jive Apps Market will require another CNAME entry for the apps CN to point to the apps hosted domain.


    The best way to deal with the UCC SSL cert is with a primary name and aliases for UAT nodes.  This allows Jive to install one cert on all of the load balanced Virtual IPs and the customer has only one SSL cert to purchase and manage.


    This is an example DNS layout which shows a typical Common Name format and the corresponding Jive Hosted Domain it would be pointed to via a CNAME record; actual entry details will be unique to each customer and are supplied by Jive Hosting on in the SSL setup case:


    Virtual InterfaceCommon NameJive Hosted Domain



    More About Akamai

    • Akamai's customer certificates are issued by Akamai, and the DNS entries will differ from those referenced above. Akamai uses an "edgekey" instead of your Jive Hosted URL ( in order to route traffic properly.
      • You will also be required to create a self-signed certificate to Jive that will be placed on your Jive Virtual IPs. Below is the command you can use to create the self-signed certificate:
        • openssl req -x509 -nodes -newkey rsa:2048 -keyout <keyfilename>.key -out <certificate-filename>.crt
    • The Akamai implementation involves Domain Control Validation. This is a process in which the CA (Certificate Authority) verifies ownership of the domain. This is performed in one of two ways:
      • Email-Based: You will be sent an email to an administrative contact for your domain. The email will contain a unique validation code and link. Clicking the link and entering the code will prove domain control. Valid email addresses are:
        • Any email address which the CA system can scrape from a port 43 WHOIS check;

        • The following generic admin type email addresses @ the domain for which the certificate is being applied: admin@, administrator@, postmaster@, hostmaster@, and webmaster@

      • File-Based: Akamai will send a text file to the Jive Hosting Engineer, who will then upload the file to your instance so Akamai can verify the presence of the file.