Something completely different: changing the SSL certificate on MobileIron Core and Sentry. In total, I had to replace 5 certificates. 4 certificates are replaced via the Core web interface and 1 certificate needs to be replaced via the Sentry web interface.
Within the Core web interface you have to change the certificated in two separate interfaces.
1. Login to the Core web interface and choose Services >> Sentry
2. Choose the icon (person’s head) in the upper right corner >> System Manager. Log in to the System Manager website and choose Security >> Certificate Mgmt
Log in to the Sentry web interface and choose Security >> Certificate Mgmt
The process of replacing the certificate is the same for all 5 certificates. You only need to be careful to upload the correct certificates. In my situation, users are connecting to two different FQDNs. One FQDN is pointing to the Core and is used to sign in to MobileIron and register a device. The second FQDN points to Sentry and is used for client connections from the mobile device, like Outlook Sync or Web@Work. I upload the certificate with the Sentry FQDN to the Sentry option on the Core web interface and within the Sentry web interface and I upload the Core certificate within the Core System Manager web interface.
I am using a certificate based on a full FQDN, so no wildcard certificate. The certificate’s certificate path contains two intermediate certificates and one root certificate. In total I have 5 different files:
I upload all certificates separately when choosing Manage Certificate like shown in the image.
Hit Upload Certificate when you choose all the necessary files. MobileIron starts uploading the certificates, is “smart” enough to combine all certificates, replaces the certificate for the specific service and restarts the service. This could result in a short interruption of production. After this, the SSL certificate is successfully replaced.
I would like to upgrade my current NetScaler VPX Express configuration via GUI. For some security reason Internet Explorer and FireFox aren’t able to access the GUI. They return the error message that the NetScaler is using a wrong SSL certificate.
The default SSL self-signed certificate is installed on the appliance. I have uploaded a “real” certificate to content switch and load balancing. I would like to use the same certificate for GUI management. To change the certificate, access the NetScaler via SSH.
Check the current certificate run the following command and you will get the following output.
sh run | grep “bind ssl service”
bind ssl service nshttps-::1l-443 -certkeyName ns-server-certificate
bind ssl service nsrpcs-::1l-3008 -certkeyName ns-server-certificate
bind ssl service nskrpcs-127.0.0.1-3009 -certkeyName ns-server-certificate
bind ssl service nshttps-127.0.0.1-443 -certkeyName ns-server-certificate
bind ssl service nsrpcs-127.0.0.1-3008 -certkeyName ns-server-certificate
If you would like to see all your available certificate enter the following command.
> sh run | grep “ssl certKey”
add ssl certKey ns-server-certificate -cert ns-server.cert -key ns-server.key
add ssl certKey wildcart-booches-nl -cert sslcert-wildcard-booches-nl.pem -key passwd-private-wildcard-1route-nl.pem -passcrypt “adfadf&*fU=”
add ssl certKey root-booches -cert cacert.pem
I would like to bind the certificate “wildcard-booches-nl”, so I use the following commands to bind the certificate to the different management services.
bind ssl service nskrpcs-127.0.0.1-3009 -certkeyName wildcard-booches-nl
bind ssl service nshttps-127.0.0.1-443 -certkeyName wildcard-booches-nl
bind ssl service nsrpcs-127.0.0.1-3008 -certkeyName wildcard-booches-nl
When configuring a Microsoft ISA Server 2006 array you have two options for authentication and communication between the Microsoft ISA 2006 Configuration Storage Server and the array members.
I normally configure the array members within a DMZ environment en install the CSS server on the internal network.
To maximize the security the array members aren’t part of the Active Directory. So communication between the CSS and the array members is workgroup based and the authentication type used is Authentication over SSL encrypted channel. This option needs the configuration of SSL certificates to authenticate and secure the connection. The certificates have a certain validity period, after which the certificate needs to be renewed.
Normally I always ran the repair option from the installation and specified the new certificate. I discovered a new and simpler method by using the ISACertTool. This tool provides an easy way to renew the certificate on the Configuration Storage Server and the root CA certificate on the array members.
You just need to create a web server certificate in pfx format from a Windows CA server of any other CA server. If the CA server isn’t trusted by the array members, you need to install the CA certificate on the array members. If you use trusted CA server certificate, you can skip this step.
The syntax for the ISACertTool is very straightforward. On the Configuration Storage Server you need to run the following command:
ISACertTool.exe /st <pfx file> /pswd <password> /keepcerts
On the array member you run the following command to install the root CA certificate.
ISACertTool.exe /fw <root ca file>
IMPORTANT: for a correct usage of the tool you need to extract the tool to the Microsoft ISA Server install directory, which is by default C:\Program Files\Microsoft ISA Server.
I had to troubleshoot a Cisco ASA today, where the client wasn’t able to connect to the management web interface anymore via https. The customer didn’t install ASDM locally, but always starts the Java-based version.
After upgrading the Cisco ASA to software version 8.2(1) and a reboot, the client wasn’t able to connect to the web interface anymore. I was able to connect to the firewall with my locally installed ASDM client, but I couldn’t access the web interface either.
While troubleshooting I first tried the basic settings, like management access-list, regenerate crypto keys and change the management port. All these options didn’t help, but the strange thing was that the web interface was working remotely.
While working with Mozilla I received the following error:
cannot communicate securely with peer: no common encryption algorithm(s).
In Google Chrome I receive the following error:
Error 113 (net::ERR_SSL_VERSION_OR_CIPHER_MISMATCH): Unknown error.
And of course Internet Explorer didn’t gave any usable information. I started looking at the supported encryption algorithms within the firewall with a show version. I noticed that VPN-3DES-AES was disabled. The next step was the enable the VPN-3DES-AES ciphers. The upgrade license for this feature is available for free at http://www.cisco.com/go/license.
I activated the VPN-3DES-AES feature, but still wasn’t able to connect to the firewall with the web interface. I checked the SSL encryption used by the firewall.
fw01# show ssl
Accept connections using SSLv2, SSLv3 or TLSv1 and negotiate to SSLv3 or TLSv1
Start connections using SSLv3 and negotiate to SSLv3 or TLSv1
Enabled cipher order: des-sha1
Disabled ciphers: 3des-sha1 rc4-md5 rc4-sha1 aes128-sha1 aes256-sha1 null-sha1
No SSL trust-points configured
Certificate authentication is not enabled
The firewall still didn’t enable the ciphers supported in my browser. If the VPN-3DES-AES license isn’t installed, only the cipher des-sha1 is enabled by default. I added the correct ciphers with the following command:
fw01(config)# ssl encryption aes256-sha1 aes128-sha1 3des-sha1
After adding the command I was able to connect to the ASA with both the web interface and the ASDM.
Today I have been troubleshooting a Citrix NetScaler configuration, where some clients received the Protocol Driver Error message when executing a published application. This error message is mostly related to a wrong configuration of the Security Ticket Authorities (STA’s). I spent a lot of time troubleshooting this issue and focused on the STA configuration. I have been deleting, adding and modifying multiple STA’s to the configuration of the NetScaler without any luck. I checked the configuration of the firewall, but this wasn’t the problem either.
I decided to go back to basic and just added one STA to the Virtual Server and the STA service group used by the Web Interface. I was able to login with that STA server, but after a while I wasn’t able to login and received the Protocol Driver Error again.
While browsing through the NetScaler I noticed one thing. Every time I wasn’t able to login, there were 5 concurrent users already connected with the NetScaler. I did some more research on the internet and found the following article.
Reading the article, tells me that, by default, only 5 concurrent ICA sessions are possible through the NetScaler. I checked the license and the customer has a license for 50 SSL VPN connections, like shown below:
> show license
Web Logging: YES
Surge Protection: NO
Load Balancing: YES
Content Switching: YES
Cache Redirection: NO
Sure Connect: NO
Compression Control: NO
Delta Compression: NO
Priority Queuing: NO
SSL Offloading: YES
Global Server Load Balancing: NO
GSLB Proximity: NO
Http DoS Protection: NO
Dynamic Routing: YES
Content Filtering: YES
Integrated Caching: NO
SSL VPN: YES (Maximum users = 50)
OSPF Routing: NO
RIP Routing: NO
BGP Routing: NO
IPv6 protocol translation: YES
Application Firewall: NO
HTML Injection: NO
NetScaler Push: NO
I increased the default value to 50 with the following command:
> set aaa parameter -maxAAAUsers 50
From that point on I was able to start another ICA connection, while there were already 5 concurrent users connected. Now I have to wait and see if this actually solved the problem, but I guess it has.
I tried to increase the –maxAAAUsers value to a value higher than 50, but that isn’t possible as you can see.
> set aaa parameter -maxAAAUsers 100
ERROR: MaxAAAUsers value not allowed by license