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
While configuring Office365 as the messaging (SMTP) server within Aruba ClearPass, I needed to upload the certificate from the StartTLS session to the certificate trust list from ClearPass. I had to export the certificate for smtp.office365.com via the following OpenSSL command:
openssl s_client -showcerts -starttls smtp -crlf -connect smtp.office365.com:587
After running the command, you will see some output like shown in the image.
I copied the both parts between BEGIN CERTIFICATE and END CERTIFICATE to two different text editore files and saved them with the extension .cer. Next I was able to upload both certificates to the certificate trust list in ClearPass and configure the message server with StartTLS Connection Security
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.
A lot of appliances and/or security solutions use LDAP to synchronize users from an Active Directory or an eDirectory environment. Active Directory is LDAP enabled by default. If you would like to harden your network, you would like to use LDAPS.
LDAPS is a term to refer to LDAP communication over SSL. Intercepted LDAPS traffic cannot be read easily by hackers. In an Active Directory environment you need to have at least one Certificate Authority (CA) to enable LDAPS. Windows uses Server Authentication certificates for the LDAPS operations.
Last week I had a customer complaining that people weren’t able to access their webmail via a Microsoft ISA reverse proxy. The cause of the problem was an expired Server Certificate on the specific domain controller. The reverse proxy server uses LDAPS to authenticate the user against an Active Directory. The following event log was found on the reverse proxy server.
To resolve the problem I had to renew the Server Authentication certificate on the domain controller. I decided to use the “Windows method” by using the Windows CA to renew the certificate. From the domain controller with the expired certificate I opened IE and enter the URL:
http://<IP address CA>/certsrv
This opens the Microsoft Certificate Services webpage of the CA. The following screenshots show the request and installation procedure for the certificate renewal.
Normally I use OpenSSL to generate the certificate signing request, which is submitted to the CA. In that scenario I had to choose option 2. This time I decide to generate the csr via the webpage and choose the first option: Create and submit a request to this CA.
The csr is generated with the information from the screenshot above. Because I had to renew a Server Authentication certificate, I choose the Web Server certificate template. The Name field is very important and should match the FQDN of the LDAPS server. It is also important to select the Store certificate in local computer certificate store option. This ensures that the certificate isn’t installed in the user’s certificate store, because the certificate cannot be exported with private key.
When you submit the certificate request, you have to wait until the request is approved. The approval has to be done by someone who manages the CA environment. If you open the CA MMC snap-in you will see one or more pending request. The pending request needs to be approved. After the request was approved, I browsed to the Microsoft Certificate Services webpage, like shown below.
I choose the option View the status of a pending certificate request. Remember that I did the whole procedure on the LDAPS server to be sure that the certificate is stored in the servers local computer certificate store. The last step involves installing the certificate in the local computers certificate store. After the installation I always check the store to see if the private key is present for the certificate.
The renewal of the certificate is almost done. The LDAPS services depends on the process LSASS.exe. To “associate” the SSL certificate with the LDAPS server I needed to reboot the server. During the reboot the first valid Server Authentication SSL certificate within the local computer certificate store is used by the LDAPS server.
The reverse proxy server was able to use LDAPS again after the reboot of the specific domain controller.