Frequently Asked Questions

Following steps are applicable for all versions of IIS. Windows Server should be domain joined.

1. Open the MMC console and add the Certificate snap-in to it as Local Computer. Right Click Personal node on the left and Select All Tasks –>Advanced Operations –> Create Custom Request.
2. Choose Proceed without enrollment policy and Click Next. Choose No Template Legacy Key for compatibility reasons. Use PKCS#10.
3. Click Next and click Properties. Give a friendly name for the certificate and a description. Ensure that you hit Apply as soon as you are done with the tab.
4. Click on Subject tab and add all the hostnames under “Alternative Name“. Under Subject Name, enter the Common Name (CN), Organizational Unit (OU), Organization (O), State (S) and Country (C) values. Click Apply.
5. Under the Extensions tab, expand Extended Key Usage (application policies) and select Server Authentication and Client Authentication. Click Apply.
6. Under the Private Key tab, set the Key size to 2048 under Key options. Tick Make Private Key exportable. Select Exchange as the Key type. Click Apply. Click OK.
7. Select a location to save the file. Choose the file format as Base 64. Click Finish.

CSR is generated with SAN values.

Installation of SSL Certificate in Windows Azure environment is different. It requires a special password protected PFX file with Triple DES encryption. Please mention this requirement while placing request to us. We will send this special PFX file.

Installation steps are given on this blog.

When an internal/external IP Address is part of Common Name (CN) or Subject Alternative Name (SAN) care needs to be taken while generating the CSR.

If not done correctly then the latest browsers like Chrome and Edge give an error – “Your connection to this site is not secure.” Note that deprecated Microsoft Internet Explorer does not give any error in this case.

To avoid this problem please ensure that the IP address is mentioned in the SAN extension as DNS Name and IP Address.

A sample configuration file is shown below for Multi-domain Certificate with 1+3 SAN values, where CN has IP-Address-1 and SAN values are IP-Address-2, SAN-1, and SAN-2.

———

[req]
prompt = no
distinguished_name = dn
req_extensions = ext

[dn]
CN = IP-Address-1
O = Org Name
L = Location/City
ST = State/Province
C = 2 digit code

[ext]
subjectAltName = @alt_names

[alt_names]
IP.1 = IP-Address-1
IP.2 = IP-Address-2
DNS.1 = IP-Address-1
DNS.2 = IP-Address-2
DNS.3 = SAN-1
DNS.4 = SAN-2

———

If you asked for the Intranet SSL without CSR, you would have received server.pfx file on email.

1. Copy the server.pfx file to the Ubuntu machine
2. Ensure that openssl package is installed on Ubuntu
3. Run the following command:
sudo openssl pkcs12 -in server.pfx -passin pass:inetssl2 -out serverpfx.pem -nodes
This will create a serverpfx.pem file, which contains the issued certificate, two CA certificates and the private key.
4. Move the serverpfx.pem file to /etc/ssl/certs/
5. Update the permissions:
sudo chmod 644 /etc/ssl/certs/serverpfx.pem
6. Restart the Apache service:
sudo service apache2 restart

In case, you wish us to make the serverpfx.pem file, write back to us on support@intranetssl.net

Good question.

It is always recommended to generate CSR on your web server and share with us.  This is because the private key generated during the CSR generation remains on your server, within your premises.

On the other hand, if you give certificate details to us, we generate the CSR. It is called Auto-CSR. During this process, private key is generated on our machine. When we ship the Intranet SSL to you, we send the SSL certificate along with the private key. This method is slightly risky because the private key can be intercepted by someone when it is sent through email.

But generation of CSR for Intranet SSL poses some technical challenges. Reason is that modern browsers expect the CSR to have require SAN values correctly specified.

For example, if the Common Name is “abc.local” then the CN=abc.local and SAN value should be DNS=abc.local. But it is not easy to generate CSR with SAN values on Windows or Linux.

Another issue comes when the certificate is to be issued to an IP address. In this case SAN should have two values. They are DNS=[IP-address] and IP=[IP-Address].

If any of these SAN values are not specified while generating the CSR then browser gives ‘Certificate not Trusted’ error.

Of course, we have shared the steps to generate CSR with SAN values. Link is given below.

https://intranetssl.net/ufaq/how-to-create-the-csr-with-san-in-windows-iis/

https://intranetssl.net/ufaq/how-to-create-csr-with-san-values-using-openssl/

Following steps are applicable for all versions of IIS. Windows Server should be domain joined.

1. Open the MMC console and add the Certificate snap-in to it as Local Computer. Right Click Personal node on the left and Select All Tasks –>Advanced Operations –> Create Custom Request.
2. Choose Proceed without enrollment policy and Click Next. Choose No Template Legacy Key for compatibility reasons. Use PKCS#10.
3. Click Next and click Properties. Give a friendly name for the certificate and a description. Ensure that you hit Apply as soon as you are done with the tab.
4. Click on Subject tab and add all the hostnames under “Alternative Name“. Under Subject Name, enter the Common Name (CN), Organizational Unit (OU), Organization (O), State (S) and Country (C) values. Click Apply.
5. Under the Extensions tab, expand Extended Key Usage (application policies) and select Server Authentication and Client Authentication. Click Apply.
6. Under the Private Key tab, set the Key size to 2048 under Key options. Tick Make Private Key exportable. Select Exchange as the Key type. Click Apply. Click OK.
7. Select a location to save the file. Choose the file format as Base 64. Click Finish.

CSR is generated with SAN values.

Installation of SSL Certificate in Windows Azure environment is different. It requires a special password protected PFX file with Triple DES encryption. Please mention this requirement while placing request to us. We will send this special PFX file.

Installation steps are given on this blog.

When an internal/external IP Address is part of Common Name (CN) or Subject Alternative Name (SAN) care needs to be taken while generating the CSR.

If not done correctly then the latest browsers like Chrome and Edge give an error – “Your connection to this site is not secure.” Note that deprecated Microsoft Internet Explorer does not give any error in this case.

To avoid this problem please ensure that the IP address is mentioned in the SAN extension as DNS Name and IP Address.

A sample configuration file is shown below for Multi-domain Certificate with 1+3 SAN values, where CN has IP-Address-1 and SAN values are IP-Address-2, SAN-1, and SAN-2.

———

[req]
prompt = no
distinguished_name = dn
req_extensions = ext

[dn]
CN = IP-Address-1
O = Org Name
L = Location/City
ST = State/Province
C = 2 digit code

[ext]
subjectAltName = @alt_names

[alt_names]
IP.1 = IP-Address-1
IP.2 = IP-Address-2
DNS.1 = IP-Address-1
DNS.2 = IP-Address-2
DNS.3 = SAN-1
DNS.4 = SAN-2

———

Step by step instructions on how to import the SecureNT Intranet SSL Certificate PFX file in Windows IIS Server (any version). It’s a two-step process.

Step-1: How to Import the PFX File in IIS

1. From the Start menu, type MMC, and click OK
2. In the User Account Control window, click Yes
3. In the Console window, in the menu at the top, click File > Add/Remove Snap-in.
4. In the Add or Remove Snap-ins window, under Available snap-ins click Certificates and then, click Add.
5. In the Certificates snap-in window, choose Computer account and then, click Next.
6. In the Select Computer window, select Local computer: (computer this console is running on), and then, click Finish.
7. In the Add or Remove Snap-ins window, click OK.
8. From the Console window, from the Console Root folder, expand Certificates (Local Computer) (the certificate file will be in Personal or Web Hosting folder).
9. Right-click on the certificate file which you want to import and then click All Tasks > Import
10. On the Welcome to the Certificate Import Wizard page, click Next.
11. Follow the instructions to import the primary SSL certificate from the PFX file
12. On the Certificate Store page, select Automatically select the certificate store based on the type of certificate.
13. Double-check your settings and then click Finish

You should see “The import was successful” message.

Step-2: How to Enable the SSL Certificate

1. From the start menu, search for Administrative Tools, open it, and double-click on Internet Information Services (IIS) Manager.
2. Under Connections, expand your server’s name, expand Sites, and then, click the site that you want to encrypt.
3. In the Actions menu, under Edit Site, click Bindings.
4. In the Site Bindings window, click Add.
5. In the Add Site Binding window, from the drop-down lists select: HTTPS, All Unassigned, and enter port 443.
6. From the SSL certificate drop-down list, select the certificate you want to import
7. Click OK and restart your IIS server

SecureNT Intranet SSL certificate is now installed on IIS.

Following article has the steps shown with screen-shots.

How to Import the SSL Certificate w/Private Key .pfx File

Zip file sent by us has the server certificate (server.pfx) in PFX (PKCS12) format. It needs to be imported into the Tomcat/JBoss Keystore file.

To import the SecureNT Intranet SSL Certificate into the Tomcat/JBoss Keystore, use the following command.

keytool -importkeystore -deststorepass inetssl2 -destkeypass inetssl2 -destkeystore [tomcatjbosskeystorefile] -srckeystore server.pfx -srcstoretype PKCS12 -srcstorepass inetssl2 -alias [tomcat/jboss]

In the above command replace the [tomcatjbosskeystorefile] with the Tomcat/JBoss Keystore file you have on your computer.

Also Check: Tomcat keeps its configuration information in the server.xml file. Make sure Tomcat is reading the correct Tomcat/Jboss Keystore file and that port 8443 is enabled for secure connections.

If you asked for the Intranet SSL without CSR, you would have received server.pfx file on email.

1. Copy the server.pfx file to the Ubuntu machine
2. Ensure that openssl package is installed on Ubuntu
3. Run the following command:
sudo openssl pkcs12 -in server.pfx -passin pass:inetssl2 -out serverpfx.pem -nodes
This will create a serverpfx.pem file, which contains the issued certificate, two CA certificates and the private key.
4. Move the serverpfx.pem file to /etc/ssl/certs/
5. Update the permissions:
sudo chmod 644 /etc/ssl/certs/serverpfx.pem
6. Restart the Apache service:
sudo service apache2 restart

In case, you wish us to make the serverpfx.pem file, write back to us on support@intranetssl.net

One can use Microsoft Group Policy to install SecureNT CA certificates on large number of PCs automatically. Here is link to our blog which explains how to do it.

Please follow the below steps.

a. Android 11+ Device

In Android 11+, to install a CA certificate, users need to manually:

1. Open Device settings
2. Go to ‘Security’
3. Go to ‘Encryption & Credentials’
4. Go to ‘Install from storage’ or ‘Install a certificate’ (depending on devices)
5. Select ‘CA Certificate’ from the list of types available
6. Accept a warning alert.
7. Browse to the certificate file on the device and open it
8. Confirm the certificate installation

b. On recent Samsung device:

Settings
-> Biometrics and security
-> Other security settings
-> Install from device storage
-> CA Certificate
-> Install Anyway

Check this:

1. Please check if you have installed Intranet Root/Intermediate CA Certificates on Windows PCs or Macs. If they are already installed then it could be an antivirus blocking access to the root certificate, thinking that is not a trusted root certificate. In this case, create an exception in the setting of the anti-virus to allow access to SecureNT Intranet root/intermediate CA certificates.
2. On Windows PCs ensure that Intranet Root CA Certificate is installed under “Trusted Root Certification Authorities”; and that Intranet Intermediate CA Certificate is installed under “Intermediate Certification Authorities”.

To install the SecureNT Intranet Root/Intermediate CA Certificates follow the steps given here. They need to be installed once, on each Windows client PC. On a Mac, customers will need to open Keychain Manager and explicitly trust each of the two root certificates.

To automate the installation of root certificates on multiple machines, one can use Microsoft’s Group Policy for PCs; and Parallel’s Device Management for Macs. Click here to find the installation details. (https://intranetssl.net/support/resources/)

Firefox does not use the operating system’s certificate store for storing the root certificates. So, the root certificate chain is added differently. Read this article for details. (https://support.mozilla.org/en-US/kb/setting-certificate-authorities-firefox)

Good question.

It is always recommended to generate CSR on your web server and share with us.  This is because the private key generated during the CSR generation remains on your server, within your premises.

On the other hand, if you give certificate details to us, we generate the CSR. It is called Auto-CSR. During this process, private key is generated on our machine. When we ship the Intranet SSL to you, we send the SSL certificate along with the private key. This method is slightly risky because the private key can be intercepted by someone when it is sent through email.

But generation of CSR for Intranet SSL poses some technical challenges. Reason is that modern browsers expect the CSR to have require SAN values correctly specified.

For example, if the Common Name is “abc.local” then the CN=abc.local and SAN value should be DNS=abc.local. But it is not easy to generate CSR with SAN values on Windows or Linux.

Another issue comes when the certificate is to be issued to an IP address. In this case SAN should have two values. They are DNS=[IP-address] and IP=[IP-Address].

If any of these SAN values are not specified while generating the CSR then browser gives ‘Certificate not Trusted’ error.

Of course, we have shared the steps to generate CSR with SAN values. Link is given below.

https://intranetssl.net/ufaq/how-to-create-the-csr-with-san-in-windows-iis/

https://intranetssl.net/ufaq/how-to-create-csr-with-san-values-using-openssl/

This sometimes happens due to Antivirus or End Point Security software. They don’t trust non-public Root Certificates and tell the browser that the Intranet Root Certificate is not trusted.

In one case, we noticed that AVG antivirus intercepted the network connection by keeping its own SSL in between, passing an error to the browser that SecureNT Root Certificate is not trusted. The customer created an exception for the error and the browser error stopped.

This problem is not seen with Avast antivirus. Just for information.