Frequently Asked Questions

Say, you wish to secure, say an entire range of IP addresses from 192.168.52.1 to 192.168.51.255.

For this, is it possible to buy Wildcard SSL for 192.168.52.*?

Unfortunately, no. That’s not possible.

For securing this IP address range, either one can buy Single Domain for each IP or Multi-Domain Intranet SSL certificate with required IP address in SAN values.

We issue Intranet SSL to all internal names, whether they use any regular TLD or not.

Some Private Certifying Authorities do not issue Intranet SSL if your internal domain name uses a regularly used Top Level Domain (TLD) name, including ccTLD reserved for countries.

For example, if your internal domain name is name1.com or name2.net, or name3.us then they won’t issue Intranet SSL Certificate to you. They will insist that you buy their regular SSL Certificate issued by a public CA.

Internal names include hosts and domains that cannot be registered or resolved in public DNS e.g., server01 or server.local, localhost, etc.

Internal IP addresses cannot be registered for use on public networks. They include IPv4 or IPv6 addresses the Internet Assigned Numbers Authority (IANA) marks as reserved. The most common reserved ranges are 10.0.0.0-10.255.255.255, 172.16.0.0-172.31.255.255, and 192.168.0.0- 192.168.255.255. More information is available here.

TLD is the acronym used for top-level domain. It’s the last segment of a domain name after the final dot.

A great example of a TDL is: .com

The IANA officially recognizes three types of TLDs:

• gTLD – Generic Top-Level Domains
• ccTLD – Country Code Top-Level Domains
• sTLD – Sponsored Top-Level Domains

Your TLD plays an important role in the Domain Name System (DNS). For more information click here.

Intranet SSL certificate’s root certificate chain is not trusted by default on popular browsers like Chrome, Edge, Internet Explorer, Safari, Firefox, etc. This means that unless certain steps are taken, a client PC will get a “certificate not trusted” error when a user uses a web browser to access a website hosted on a Server with Intranet SSL.

But these steps (installation of SecureNT CA root certificates) need to be taken once only. After those steps are taken, the client PC will always trust the Intranet SSL certificate.

You can find the steps here.

Say, you wish to secure, say an entire range of IP addresses from 192.168.52.1 to 192.168.51.255.

For this, is it possible to buy Wildcard SSL for 192.168.52.*?

Unfortunately, no. That’s not possible.

For securing this IP address range, either one can buy Single Domain for each IP or Multi-Domain Intranet SSL certificate with required IP address in SAN values.

• Certificates are issued by default with RSA Encryption, 2048 bit Key Size, and Sha256 Hash Algorithm
• The Root Certificate chain is from Secure Network Traffic
• Custom Root Certificate chain on your organization name is available on request
• Client Authentication Certificates for Single Sign-on and Document Management / Signing available on request.
• RSA Certificates with different Key Size and Hash Algorithm available on request
• ECDSA Certificates with 256 and 384-bit Key Size also available on request

We issue Intranet SSL to all internal names, whether they use any regular TLD or not.

Some Private Certifying Authorities do not issue Intranet SSL if your internal domain name uses a regularly used Top Level Domain (TLD) name, including ccTLD reserved for countries.

For example, if your internal domain name is name1.com or name2.net, or name3.us then they won’t issue Intranet SSL Certificate to you. They will insist that you buy their regular SSL Certificate issued by a public CA.

For creating CSR with SAN values (X.509 v3 Extension) it’s important to create a configuration file with the required certificate details. Execute following command in openssl.

openssl req -newkey rsa:2048 -nodes -keyout pvtkey.cer -config config.cnf -out csr.txt -utf8

It will create a Private key (pvtkey.cer) and CSR file (csr.txt).

Sample Configuration file (config.cnf)

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

[dn]
CN = 192.168.2.23
O = Abc Corporation
L = Sydney
ST = New South Walse
C = AU

[ext]
subjectAltName = @alt_names

[alt_names]
IP.1 = 192.168.2.23
IP.2 = 10.12.4.122
DNS.1 = 192.168.2.23
DNS.2 = 10.12.4.22
DNS.3 = sms.abc.local
DNS.4 = localhost

It will generate CSR with CN=192.168.2.23 and 3 SAN values: 10.12.4.122, sms.abc.local and localhost.

Notice that when IP address is there in CN or SAN, we need to put its value against both IP Address and DNS. For others (URL, Servername etc) only DNS value is required.

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

We issue SecureNT Intranet SSL certificate in PEM format with .cer extension.

The PEM format is the most common format used for certificates. Extensions used for PEM certificates are cer, crt, and pem. They are Base64 encoded ASCII files.

PEM formatted certificates contain the “Begin Certificate/End Certificate” statements.

The DER format is the binary form of the certificate. DER formatted certificates do not contain the “BEGIN CERTIFICATE/END CERTIFICATE” statements.

DER formatted certificates most often use the ‘.der’ extension. Root Certificates on Resource page are in DER format.

In case, you want them in PEM format send Email to support@intranetssl.net

Not necessary.

Just fill-up the form and we will generate the CSR (called Auto-CSR). And we will send the SSL Certificate along with the private key.

Internal names include hosts and domains that cannot be registered or resolved in public DNS e.g., server01 or server.local, localhost, etc.

Internal IP addresses cannot be registered for use on public networks. They include IPv4 or IPv6 addresses the Internet Assigned Numbers Authority (IANA) marks as reserved. The most common reserved ranges are 10.0.0.0-10.255.255.255, 172.16.0.0-172.31.255.255, and 192.168.0.0- 192.168.255.255. More information is available here.

• Secure localhost, Server Name, Internal IP Address, Internal Domain, Sub-domain including Wildcard domain e.g., *.company.local
• Secure multiple servers using SAN values
• Certificates valid up to 10 years
• Install the same certificate on unlimited servers
• The certificate is issued with SecureNT Intranet Root & Intranet Intermediate CA chain. They are to be installed on each client’s machine.
• Fast Issuance, usually less than 24 hours
• Fast Expert Customer Support
• Automatic renewal reminders and early renewal options
• 30-day free certificate for Single Domain. 7-day free certificate for Multi-domain and Wildcard.
• Certificates with Custom Root CA in the name of your Organization are available
• Client Authentication Certificates for Web-based Applications and Document Management Systems available

TLD is the acronym used for top-level domain. It’s the last segment of a domain name after the final dot.

A great example of a TDL is: .com

The IANA officially recognizes three types of TLDs:

• gTLD – Generic Top-Level Domains
• ccTLD – Country Code Top-Level Domains
• sTLD – Sponsored Top-Level Domains

Your TLD plays an important role in the Domain Name System (DNS). For more information click here.

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

———

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/