FlexNet Operations Knowledge Base

Redis Host and Redis Port in the System config under FlexNet Platform Server

Redis Host and Port config have been introduced to fix a "Vulnerability" which is WhiteHat: CVSS V3 - 6.5 : Vulnerability ID : 52269953. However, as of now, the Redis instances are provisioned and available yet to leverage caching for session manag...

mrathinam Revenera Moderator Dec 09, 2021

host port redis System Configuration

Featured Articles

Featured article

Introduction The SSL (Secure Sockets Layer) certificate for FlexNet Operations Cloud is updated annually. Periodically the intermediate (about every 10 years) and root (about every 20 years) certificates are also updated. The FlexNet Embedded local license server relies on the intermediate and root certificate chain to communicate with FlexNet Operations Cloud. The following instructions are best practices to have a local license server prepared for this and other future certificate updates in FlexNet Operations Cloud. Who Should Read This Article? The intended audience for this article includes FlexNet Embedded local license server administrators, who need to ensure that their license servers are properly configured for an SSL certificate update. (The "you" in this article is the local license server administrator.) Producers should also read this article to understand what the local license server administrator at each of their customer sites must do to prepare for an upcoming certificate update. Producers need to keep the license server administrators informed of announcements about upcoming certificate updates and expirations. With support from producers, license server administrators can have adequate time to prepare their license servers for certificate upgrades and test a new certificate in UAT before the old certificate actually expires. Local License Servers 2021.05 or Later In general, a certificate update is not a concern for FlexNet Embedded local license servers built with the 2021.05 or newer FlexNet Embedded kits as these servers default to using the “cacerts” file included with Java. The “cacerts” file is maintained and updated by Java. Certificate authorities start issuing new intermediate and root certificates 1-2 years before their actual expiration date. This allows time for the “cacerts” file to be updated well before the change occurs with certificates for FlexNet Operations Cloud. Keeping Java updated to the latest version supported by your local license server helps to ensure that the server's certificate information will be properly synchronized with the FlexNet Operations Cloud certificates whenever certificate updates go into effect. (Refer to the FlexNet Embedded License Server Release Notes for the latest versions of Java supported by the license server.) Local License Servers 2021.03 or Earlier If you are using a local license server built with FlexNet Embedded 2021.03 or earlier, check the truststore path in the server’s “local-configuration.yaml” file. (On Linux, this file is found in the “/opt/flexnetls/producer” directory. On Windows, it is located in the same directory as “flexnetls.jar”.) If this file is configured to use the “cacerts” file as its truststore, no action is needed. If the file is configured to use the “flexnet.certs” file, the license server administrator can perform one of these two options. Whichever option is used, the license server administrator should make sure that the Java version is kept up to date with the latest version supported by the local license server. (See the FlexNet Embedded License Server Release Notes for this information.) Option 1 First, update the “local-configuration.yaml” so that it contains the path to the Java “cacerts” file, as shown in the following example: # Path to truststore containing server certificate. truststore-path: ${JAVA_HOME}/jre/lib/security/cacerts Then, for the “truststore-password” property, enter the password for the “cacerts” truststore. Note that, if the password was not previously changed from its default value, enter the default password “changeit”. However, if the password was previously changed, the current password must be entered. # Truststore password. You can obfuscate this with java -jar flexnetls.jar -password your-password-here. truststore-password: changeit Alternatively, the administrator can first obfuscate the password by following the instructions included in the “yaml” file and then provide the obfuscated value, as shown is this example. truststore-password: OBF:1vn21ugu1saj1v9i1v941sar1ugw1vo0 Option 2 Install a version of the local license server built with FlexNet Embedded 2021.05 or later. Local Licenses Servers That Run Offline Except for Activations Some FlexNet Embedded local license servers run offline but occasionally go online to activate the latest licenses from the FlexNet Operations back office. To ensure that the certificate information on the license server is synchronized with FlexNet Operations before performing any activations, the license server administrator needs to do the following: Bring the offline device (containing the license server) online. Ensure that the device is upgraded with the latest version of Java supported by your license server installation. (See the FlexNet Embedded License Server Release Notes.) Ensure that the “local-configuration.yaml” file for the license server points to the “cacerts” file as its truststore. This step is especially important if your license server version is 2021.03 or earlier. For more information, see Local License Servers 2021.03 or Earlier. Perform the license activation operations. This step is important (as explained in The SSL Communication Process). Take the device offline. The SSL Communication Process During SSL communication between the server (FlexNet Operations) and a client (the local license server), an initial "handshake" occurs. During this handshake, the root certificate present in caecerts gives the client a public key to attempt validation. Once validation is successful, the connection is established and further communication can occur. For offline local license servers, bringing the license server temporarily online to perform activation operations once you have prepared it for a certificate upgrade is necessary to ensure that the initial SSL handshake using the new certificate takes place. Troubleshooting If your local license server has not been properly configured for a certificate upgrade, the license server receives the message "SSL is misconfigured" once the old certificate expires. At this point, to avoid any further license-server downtime, you must perform the steps outlined in this article to ensure that the license server is able to use the new certificate. However, because of this late configuration, you will have missed the UAT phase of the upgrade that allowed you to test the new certificate and resolve any issues before the old certificate expired. Once you have configured your machine for a certificate upgrade, it should be able to handle future certificate upgrades (as long as you keep your Java installation version up to date). However, ensure that you periodically ask your producer about the schedule of upcoming certificate upgrades and expirations so that you are aware of the timeframe for testing out any new certificate. Keeping up to date on the schedule will help you avoid unnecessary license-server downtime when an old certificate expires. Practice To Avoid Because Revenera updates the FlexNet Operations Cloud SSL certificate annually, best practice is not to hard-code the hash of this certificate in your client code. With each certificate update, the hash changes. Additional Resource If you are using API to integrate your application with FlexNet Operations, see FlexNet Operations Cloud - Digital Certificates for information about exporting and configuring SSL certificates from FlexNet Operations.

Featured article

This article explains how to install and configure digital certificates for use with the FlexNet Operations application based on your particular requirements and environment. This section contains the following topics: Exporting a Digital Certificate Trusting a Certificate in a Java Environment Keeping SSL Certificate Information on Local License Servers in Sync with Certificate Updates in FlexNet Operations Cloud Exporting a Digital Certificate However you choose to integrate with FlexNet Operations using the API, you need to export the digital certificates from FlexNet Operations to communicate securely using SSL. You must first decide whether your solution will trust all digital certificates in the certificate chain, or only the root certificate authority. Different solutions require different trust strategies. You must identify how the certificates must be trusted for your solution. The primary decision point in trusting the certificates for the Producer Portal is whether to trust all certificates in the chain. Many solutions are designed to trust all certificates under the root issuing authority. This is the preferred method and will allow your integration to continue to work after the certificate is renewed each year. Some customers choose to additionally trust the certificate from the Producer Portal to increase security. However, when the certificate is renewed on an annual basis, this requires you to take action to update the certificate store. With current SSL policy changes to require more secure connections and more frequent certificate renewals, this method is no longer valid. FlexNet Operations UAT and Production server certificates are issued by a certificate authority. Therefore, if you are relying on trusting the root authority, you only need to export the certificate once. You can do this from either the UAT or Production environment. If you need both certificates in the chain, you must export three certificates: The digital certificate The FlexNet Operations UAT certificate The FlexNet Operations Production certificate The easiest way to export a digital certificate is to use a wizard provided with Microsoft’s Internet Explorer. (The instructions, below, export the UAT server certificate.) To export a digital certificate: Open an Internet Explorer window and enter the following URL (For example: https://manageruat.flexnetoperations.com). Click the yellow padlock icon next to the address bar then click View Certificate. A window appears displaying the certificate. Select the Details tab. Click Copy to File. The Certificate Export Wizard appears. Click Next. Select the appropriate format of certificate distribution for your integration. Note: You must consult the documentation of your solution for this information. It is possible to export all the certificates in the path, depending on the formats your solution supports. Click Next. Select a file location for exporting the certificate. Name the file with a .cer extension. If you are doing this for a different certificate, name it appropriately. Click Next. Verify your choices. Click Finish. A message appears indicating the export was successful. Click OK. Close the Certificate dialog box. You will now need to import this certificate so your solution trusts the FlexNet Operations application. Trusting a Certificate in a Java Environment The Java programming language relies on the concept of a Java keystore to trust digital certificates. The creation and manipulation of these stores is done using a Java utility known as the keytool. You will use this utility to create a keystore that your Java solution can trust. Before continuing with the examples provided here for using the keytool utility, you may want to consider using Sun’s treatment of the keytool utility. A full description of this utility is provided at the following URL: http://docs.oracle.com/javase/6/docs/technotes/tools/solaris/keytool.html. Keeping SSL Certificate Information on Local License Servers in Sync with Certificate Updates in FlexNet Operations Cloud The SSL certificate for FlexNet Operations Cloud is updated annually. Periodically the intermediate (about every 10 years) and root (about every 20 years) certificates are also updated. The FlexNet Embedded local license server relies on the intermediate and root certificate chain to communicate with FlexNet Operations Cloud. For information about keeping a local license server synchronized with future certificate updates in FlexNet Operations Cloud, see the following article: Best Practice: Keeping SSL Certificate Information on Local License Servers Synchronized with FlexNet Operations Cloud

Featured article

Introduction This article provides the FlexNet Operations Cloud IP addresses for network block or IP address allow list. Need to Know A new set of network blocks is being used by FlexNet Operations Cloud services. The networks block addresses differ based on the deployment environment your FlexNet Operations Cloud is hosted on. We are migrating from the following legacy IP blocks referred in the table below. Please add the new IP blocks documented in the Best Practices section based on your FlexNet Operations instance and its deployment region. Legacy IP address blocks (for reference) Environment IPv4 Blocks IPv6 Blocks Production 64.14.29.0/24 2620:122:f001:1163::/64 UAT 64.14.29.0/24 2620:122:f001:1163::/64 Disaster Recovery (DR) 64.27.162.0/24 2620:122:f001:1163::1/128 Best Practices If you use an IP allow list, we advise using IP blocks instead of individual IP addresses as the IP addresses for a given connection may change from one call to the next. We strongly recommend sharing the following IP blocks with your IT team to add to your network block. For FlexNet Operations Cloud ALM instances: IPv4: AWS NAM: 185.146.155.0/24 IPv6: AWS NAM: 2620:122:f003::/48 -OR- Deployment Region Environment IPv4 Blocks IPv6 Blocks AWS NAM Production 185.146.155.64/27 2620:122:f005::/56 UAT 185.146.155.0/27 2620:122:f003::/56 Production Copy Service (PCS) 185.146.155.32/27 2620:122:f004::/56 AWS EU Production 185.146.152.64/27 2a07:4f80:20:200::/56 UAT 185.146.152.0/27 2a07:4f80:20::/56 NOTE: It is no longer necessary to specify an IP address block for the Disaster Recovery (DR) environment. For FlexNet Operations Cloud LLM instances: We are in the process of migrating FlexNet Operations LLM to AWS. We advise adding the following IP blocks to your network block to prepare for the upcoming migration. IPv4: AWS NAM: 185.146.155.0/24 IPv6: AWS NAM: 2620:122:f003::/48 -OR- Deployment Region Environment IPv4 Blocks IPv6 Blocks AWS NAM Production 185.146.155.64/27 2620:122:f005::/56 UAT 185.146.155.0/27 2620:122:f003::/56 Production Copy Service (PCS) 185.146.155.32/27 2620:122:f004::/56 NOTE: It is no longer necessary to specify an IP address block for the Disaster Recovery (DR) environment. Frequently Asked Questions Understanding IP Allow Listing for FlexNet Operations Cloud Q: Why do we need to allow list these blocks? A: If your organization, or your customers, operate strict firewall rules then you should allow these IP address blocks. Q: Who should we speak to about allow listing? A: You should discuss your needs with your IT administrators, who typically maintain these allow list rules. If you require further information, please contact Revenera Technical Support. Q: Which FlexNet Operations Cloud services are affected if an allow list is configured? A: All services can be impacted if you are using an allow list. Examples include: Your employees connecting to the Producer Portal UI Your end customers connecting to the Customer Portal UI Your CRM system calls FNO Web Services Your end customers' devices or Local License Servers making call-home or synchronization connections to FNO Your end customers' devices connecting to Cloud License Servers to make Capability Requests Q: Why do we need to configure an entire block – can't we just allow the IP address associated with the end point we use? A: Our advice has always been to configure the block. When we move to AWS, this is even more important, because AWS does not allocate static IP addresses; the IP address allocated to a URL can change dynamically. Understanding the AWS Migration's Affect on FlexNet Operations Cloud Allow Listing Q: When will these changes take place? A: The IP addresses were assigned on 2022-11-23 and as FlexNet Operations services were migrated over to the new AWS environment, we reminded customers to add these IP blocks to their network block to ensure continued access to FlexNet Operations services. Q: Why can't you continue to use the old IP address blocks indefinitely instead of using the new IP address blocks? A: Using the legacy IP address blocks involves complex routing rules which will impact performance, and so we must move to the new blocks as part of the AWS migration. Q: What will happen if the addresses are not added to the allow list? A: If you or your customers impose strict firewalls rules, FlexNet Operations and its services may not be accessible.

FlexNet Operations Knowledge Base