# SecureNT Private SSL and Intranet SSL Knowledge Base

## Part 1 - Introduction, Concepts, and Private SSL Fundamentals

# SecureNT Overview

SecureNT is a Private Certificate Authority (Private CA) that issues Private SSL and Intranet SSL certificates for internal networks, intranet applications, private web servers, localhost environments, internal hostnames, Active Directory domains, reserved IP addresses, SAP systems, development environments, and other non-public infrastructure.

SecureNT was created to solve a problem that public SSL Certificate Authorities cannot solve. Public SSL certificates are designed for publicly accessible websites and internet-facing services. They cannot be issued to many types of internal infrastructure that organizations continue to rely on every day.

Organizations often operate hundreds or thousands of internal systems that require encrypted communication but are not accessible from the public Internet. These systems frequently use:

* Internal hostnames
* Active Directory domains
* Localhost deployments
* RFC1918 private IP addresses
* Non-public domains
* Development environments
* Test environments
* Staging environments
* Internal APIs
* Enterprise applications

SecureNT provides Private SSL certificates specifically for these environments. SecureNT enables organizations to deploy trusted Internal HTTPS across private networks without relying on publicly trusted Certificate Authorities.

Unlike self-signed certificates, SecureNT certificates operate within a managed certificate hierarchy and support centralized trust deployment across an organization.

SecureNT certificates provide the same SSL/TLS encryption standards used by public SSL certificates while offering the flexibility required for internal infrastructure.

# What Is Private SSL?

Private SSL refers to SSL/TLS certificates issued by a Private Certificate Authority rather than a publicly trusted Certificate Authority.

The purpose of Private SSL is not to secure public websites. Instead, Private SSL is designed for:

* Internal networks
* Intranet applications
* Corporate systems
* Internal APIs
* Active Directory environments
* Development environments
* Internal databases
* ERP systems
* Manufacturing systems
* Healthcare systems
* Financial systems

Private SSL delivers the same encryption technology used by public SSL certificates.

The difference is trust.

Public SSL certificates are trusted by browsers automatically because their issuing Certificate Authorities are included in operating system and browser trust stores.

Private SSL certificates require the organization to establish trust by deploying the Root CA and Intermediate CA certificates to managed devices.

Once trust is established, users experience secure HTTPS connections exactly as they would with publicly trusted SSL certificates.

# What Is Intranet SSL?

Intranet SSL is the use of SSL/TLS certificates within a private network environment.

The term "Intranet SSL" emphasizes the deployment environment rather than the certificate hierarchy.

While Private SSL describes the certificate issuance model, Intranet SSL describes the usage model.

SecureNT uses both concepts:

* SecureNT Private SSL
* SecureNT Intranet SSL

These terms are complementary.

Organizations typically deploy SecureNT Intranet SSL certificates on:

* Internal web applications
* Human Resources systems
* ERP systems
* CRM systems
* Internal dashboards
* Manufacturing control systems
* SAP environments
* Internal SharePoint sites
* Internal APIs
* Monitoring platforms

Any application using HTTPS within a private network can use SecureNT Intranet SSL.

# Why Internal Networks Need SSL

Many organizations assume internal traffic is inherently safe.

This assumption is increasingly incorrect.

Modern internal networks contain:

* Employee devices
* Contractor devices
* Wireless networks
* Remote access systems
* VPN connections
* Cloud workloads
* Virtual machines
* Containers
* Third-party integrations

Sensitive information regularly traverses these environments.

Examples include:

* Login credentials
* Financial information
* Customer records
* Healthcare information
* Internal communications
* Production data
* Intellectual property

Without SSL/TLS encryption, this traffic can be intercepted, monitored, or modified.

SSL/TLS protects internal traffic through:

* Encryption
* Integrity validation
* Server identity verification

SecureNT Private SSL enables organizations to apply HTTPS throughout internal infrastructure.

# Who Uses SecureNT

SecureNT Private SSL and Intranet SSL certificates are used by:

- Enterprises
- Government agencies
- Educational institutions
- Healthcare organizations
- Manufacturing companies
- Financial institutions
- Software development teams
- Managed Service Providers (MSPs)

Common deployments include:

- Active Directory environments
- SAP systems
- ERP applications
- Internal APIs
- Intranet portals
- Development environments
- Test and staging systems
- Private cloud infrastructure
- Hybrid cloud infrastructure

# Why Public SSL Certificates Cannot Secure Many Internal Systems

Public Certificate Authorities operate under rules established by the CA/Browser Forum.

These rules restrict issuance for many internal identifiers.

Examples include:

* RFC1918 private IP addresses
* Localhost
* Internal server names
* Internal Active Directory names
* Certain non-public domains

As a result, organizations often discover that publicly trusted SSL certificates cannot be issued for internal systems they need to protect.

Examples include:

* 192.168.x.x addresses
* 10.x.x.x addresses
* 172.16.x.x through 172.31.x.x addresses
* localhost
* server01
* intranet
* internal Active Directory names

SecureNT was specifically designed to address these environments.

# Benefits of SecureNT Private SSL

## Same Encryption Strength

SecureNT certificates use modern SSL/TLS cryptography including:

* RSA 2048-bit keys
* SHA-256 signatures
* X.509 v3 certificates

This provides the same encryption strength expected from modern SSL deployments.

## Internal Infrastructure Support

SecureNT supports:

* Internal hostnames
* Internal domains
* Localhost
* Reserved IP addresses
* Active Directory environments

This flexibility is often unavailable through public Certificate Authorities.

## Long Validity Periods

SecureNT certificates are available with validity periods ranging from:

* 1 year
* 2 years
* 3 years
* 5 years
* 10 years

This reduces certificate management overhead for internal systems.

## Unlimited Server Licensing

SecureNT certificates include unlimited server installations.

Organizations may deploy certificates across multiple systems without per-server licensing restrictions.

## Centralized Trust

Trust can be distributed through:

* Microsoft Group Policy
* Mobile Device Management systems
* Enterprise deployment tools
* Standard certificate distribution mechanisms

# Private SSL vs Public SSL

## Public SSL

Public SSL is designed for:

* Public websites
* Internet-facing applications
* E-commerce systems
* Public APIs

Advantages:

* Browser trust is automatic
* No trust deployment required
* Ideal for public-facing services

Limitations:

* Restricted issuance policies
* Cannot support many internal identifiers
* Less flexibility for internal environments

## Private SSL

Private SSL is designed for:

* Internal systems
* Intranet applications
* Private APIs
* Active Directory environments
* Development systems

Advantages:

* Supports internal hostnames
* Supports private IP addresses
* Supports localhost
* Supports internal domains
* Greater deployment flexibility

Limitations:

* Requires trust deployment
* Intended for managed environments

For internal infrastructure, Private SSL is often the more practical solution.

# Private SSL vs Self-Signed Certificates

Organizations sometimes use self-signed certificates to secure internal systems.

While self-signed certificates provide encryption, they introduce significant management challenges.

## Self-Signed Certificates

Characteristics:

* Created individually on servers
* No centralized trust hierarchy
* Difficult to manage at scale
* Frequent browser warnings
* Inconsistent deployment practices

Problems:

* Poor user experience
* Difficult certificate lifecycle management
* Increased support burden
* Limited scalability

## SecureNT Private SSL

Characteristics:

* Managed certificate hierarchy
* Root CA and Intermediate CA structure
* Consistent trust model
* Centralized deployment
* Enterprise scalability

Benefits:

* Reduced browser warnings
* Easier administration
* Improved user trust
* Better operational control

For organizations operating more than a handful of internal systems, SecureNT Private SSL typically provides a more maintainable solution than self-signed certificates.

# Internal Names and Reserved IP Addresses

SecureNT supports certificate issuance for internal identifiers including:

## Reserved IP Addresses

Examples:

* 10.0.0.0/8
* 172.16.0.0/12
* 192.168.0.0/16

These address ranges are widely used in private corporate networks.

## Internal Hostnames

Examples:

* intranet
* server01
* fileserver
* app01
* sql01

## Active Directory Names

Examples:

* company.local
* corp.local
* internal.ad
* domain.local

## Localhost

SecureNT certificates can be issued for localhost deployments used in development, testing, and application environments.

# Summary

SecureNT Private SSL and SecureNT Intranet SSL provide a practical, scalable, and enterprise-friendly approach to securing internal infrastructure.

By supporting internal names, reserved IP addresses, localhost environments, and Active Directory deployments, SecureNT enables organizations to extend modern SSL/TLS security practices throughout their internal networks.

The following sections of this knowledge base cover certificate types, pricing, deployment models, trust distribution, certificate management, and advanced usage scenarios.

# SecureNT Private SSL and Intranet SSL Knowledge Base

## Part 2 - Certificate Types, Pricing, and Ordering

# Certificate Types Overview

SecureNT offers four primary certificate types designed to address different internal network architectures and deployment requirements.

All SecureNT certificate types provide the same underlying security technologies:

* RSA 2048-bit encryption
* SHA-256 signatures
* X.509 v3 certificates
* CRL support
* OCSP support
* Support for Server and Client Authentication (mTLS)
* Unlimited server installations
* Validity periods from 1 to 10 years
* Support for internal hostnames
* Support for reserved IP addresses
* Support for localhost deployments
* Active Directory compatibility
* Internal PKI compatibility

The primary difference between certificate types is the number and type of hostnames, domains, IP addresses, and subdomains that can be secured.

Selecting the correct certificate type is important because it directly affects cost, administration effort, future scalability, and certificate management complexity.

# Single Domain Certificate

## What Is a Single Domain Certificate?

A Single Domain Certificate secures exactly one hostname, server name, localhost instance, URL, or IP address.

This is the simplest and most affordable SecureNT certificate type.

Single Domain Certificates are ideal when an organization needs to secure a single internal application or server without additional names.

## Typical Examples

### Internal Hostnames

```text
intranet
server01
fileserver
sqlserver
erp
```

### Internal Domains

```text
erp.company.local
crm.company.local
portal.company.local
```

### Reserved IP Addresses

```text
192.168.1.100
192.168.10.20
10.10.10.10
172.16.5.50
```

### Localhost

```text
localhost
```

## Typical Use Cases

Single Domain Certificates are commonly deployed on:

* Internal HR systems
* Internal ERP systems
* Internal dashboards
* Individual application servers
* Test environments
* Development environments
* Single SAP servers
* Individual web applications

## Advantages

* Lowest cost
* Simplest deployment
* Easy certificate management
* Suitable for small environments
* Available with a 30-day trial

## Limitations

A Single Domain Certificate cannot secure multiple hostnames.

If additional names are required, a Multi-Domain certificate may be more appropriate.

# Multi-Domain (SAN) Certificate

## What Is a SAN Certificate?

A Multi-Domain Certificate uses Subject Alternative Names (SANs) to secure multiple hostnames, domains, and IP addresses within a single certificate.

A standard SecureNT Multi-Domain Certificate includes:

* 1 Primary Name
* 4 SAN Values

Additional SAN values can be purchased in groups of five.

There is effectively no practical upper limit.

## Example Configuration

```text
Primary:
erp.company.local

SAN 1:
crm.company.local

SAN 2:
files.company.local

SAN 3:
192.168.1.20

SAN 4:
192.168.1.21
```

## Typical Use Cases

Multi-Domain Certificates are commonly used for:

* Multiple application servers
* Multiple internal websites
* Internal load balancing
* Multi-server environments
* Active Directory deployments
* Development environments
* Staging environments

## Advantages

* One certificate secures multiple systems
* Reduced certificate management
* Lower operational overhead
* Supports both hostnames and IP addresses
* Supports localhost
* Highly flexible

## Advantages Over Wildcard Certificates

Unlike Wildcard Certificates, SAN Certificates can secure:

* IP addresses
* Localhost
* Different domains
* Different hostnames

This makes them the most flexible certificate type available.

## When To Choose Multi-Domain

Choose a Multi-Domain Certificate when:

* Systems use different names
* Systems use different domains
* Internal IP addresses must be secured
* Localhost must be secured
* Flexibility is more important than simplicity

# Wildcard Certificate

## What Is a Wildcard Certificate?

A Wildcard Certificate secures all subdomains beneath a single domain using the wildcard character (*).

Example:

```text
*.company.local
```

This secures:

```text
erp.company.local
crm.company.local
hr.company.local
mail.company.local
portal.company.local
```

and any future subdomains created beneath the same base domain.

## Typical Use Cases

Wildcard Certificates are popular when organizations maintain many applications under one domain structure.

Examples:

```text
*.corp.local
*.company.local
*.internal.local
*.organization.local
```

## Advantages

* Unlimited subdomain coverage
* Easy future expansion
* Simplified certificate management
* Excellent value when many subdomains exist

## Limitations

Wildcard Certificates cannot secure:

* IP addresses
* Localhost
* Different domains
* Different root domains

For these requirements, Multi-Domain or Multi-Domain Wildcard certificates should be used.

# Multi-Domain Wildcard Certificate

## What Is a Multi-Domain Wildcard Certificate?

A Multi-Domain Wildcard Certificate combines the flexibility of SAN Certificates with the broad coverage of Wildcard Certificates.

This certificate type can include:

* Wildcard domains
* Specific hostnames
* Reserved IP addresses
* Localhost entries
* Multiple domains

within a single certificate.

## Example

```text
Primary:
*.company.local

SAN 1:
*.division.local

SAN 2:
erp.internal.local

SAN 3:
192.168.10.50

SAN 4:
localhost
```

## Typical Use Cases

Multi-Domain Wildcard Certificates are often used by:

* Large enterprises
* Multi-site organizations
* Government departments
* Universities
* Healthcare systems
* Manufacturing organizations
* Complex Active Directory environments

## Advantages

* Maximum flexibility
* Reduced certificate count
* Lower administration effort
* Supports future growth
* Excellent for large environments

## When To Choose Multi-Domain Wildcard

Choose this certificate when:

* Multiple domains exist
* Multiple subdomain structures exist
* IP addresses must be secured
* Future expansion is expected
* Centralized certificate management is desired

# Certificate Comparison

## Single Domain vs Multi-Domain

Single Domain:

* One name only
* Lowest cost
* Simplest deployment

Multi-Domain:

* Multiple names
* Greater flexibility
* Lower management overhead

## SAN vs Wildcard

SAN Certificate:

* Explicitly lists names
* Supports IP addresses
* Supports localhost
* Supports different domains

Wildcard Certificate:

* Secures unlimited subdomains
* Easier for large domain structures
* Does not support IP addresses

## Multi-Domain vs Multi-Domain Wildcard

Multi-Domain:

* Multiple explicit names
* No wildcard support

Multi-Domain Wildcard:

* Multiple names
* Wildcard support
* Maximum flexibility

# Pricing

## 1-Year Pricing

| Certificate Type                  | USD  | INR     |
| --------------------------------- | ---- | ------- |
| Single Domain                     | $110 | ₹8,000  |
| Multi-Domain (1 + 4 SAN)          | $246 | ₹17,600 |
| Wildcard                          | $270 | ₹20,000 |
| Multi-Domain Wildcard (1 + 4 SAN) | $444 | ₹32,000 |

## Additional SAN Values

Additional SAN values may be added in groups of five.

For exact pricing, use the SecureNT Price Calculator.

## Discounts

Educational institutions qualify for a 30% discount.

Non-profit organizations qualify for a 30% discount.

# Free Trials

SecureNT allows organizations to evaluate certificates before purchasing.

## Single Domain Trial

* 30-day trial
* Full functionality
* Internal deployment testing

## Multi-Domain Trial

* 7-day trial
* Full functionality

## Wildcard Trial

* 7-day trial
* Full functionality

## Multi-Domain Wildcard Trial

* 7-day trial
* Full functionality

# Choosing the Right Certificate

## Choose Single Domain When

* One server must be secured
* Budget is a priority
* Expansion is unlikely

## Choose Multi-Domain When

* Multiple hostnames exist
* IP addresses must be secured
* Flexibility is required

## Choose Wildcard When

* Many subdomains exist
* One domain structure is used
* IP addresses are not required

## Choose Multi-Domain Wildcard When

* Complex environments exist
* Multiple domains are involved
* Future growth is expected
* Maximum flexibility is desired

# Ordering Process

## Step 1

Choose the certificate type.

## Step 2

Select certificate validity.

## Step 3

Provide hostname, domain, localhost, or IP information.

## Step 4

Submit a CSR or use SecureNT Auto-CSR.

## Step 5

Complete payment.

## Step 6

Receive certificate files.

## Step 7

Install certificate on servers.

## Step 8

Deploy SecureNT Root CA and Intermediate CA to client devices.

## Step 9

Verify HTTPS operation.

# Summary

SecureNT offers four certificate types that cover virtually every internal SSL deployment scenario.

For simple environments, Single Domain certificates provide the lowest-cost solution.

For mixed hostnames and IP addresses, Multi-Domain SAN certificates provide maximum flexibility.

For large subdomain deployments, Wildcard certificates simplify administration.

For complex enterprise environments, Multi-Domain Wildcard certificates provide the most comprehensive and scalable solution available within the SecureNT Private SSL and Intranet SSL platform.

# SecureNT Private SSL and Intranet SSL Knowledge Base

## Part 3 - Internal PKI, Chain of Trust, Active Directory, Deployment, CSR Generation, and Troubleshooting

# Internal PKI Fundamentals

## What Is Internal PKI?

A Public Key Infrastructure (PKI) is the framework that enables trusted digital certificates to be issued, validated, managed, and revoked.

An Internal PKI applies these principles inside an organization rather than across the public Internet.

SecureNT acts as a Private Certificate Authority (Private CA) and provides organizations with a practical Internal PKI solution without the complexity of designing, operating, and maintaining their own certificate authority infrastructure.

Internal PKI enables organizations to:

* Secure internal applications
* Secure internal APIs
* Encrypt intranet traffic
* Authenticate servers
* Support certificate-based authentication
* Centralize certificate management
* Improve internal security posture

Many organizations recognize the value of PKI but do not have the resources or expertise required to build and maintain an enterprise CA hierarchy internally.

SecureNT provides the benefits of Internal PKI while eliminating much of the operational burden.

# Why Internal PKI Matters

Modern organizations depend on:

* Internal web applications
* ERP systems
* Manufacturing systems
* Healthcare systems
* Financial applications
* Internal APIs
* Virtualized infrastructure
* Hybrid cloud deployments

Without Internal PKI, organizations frequently rely on:

* Unencrypted HTTP
* Self-signed certificates
* Expired certificates
* Inconsistent certificate practices

These approaches create security risks and operational complexity.

Internal PKI establishes a consistent trust model across the organization.

Benefits include:

* Encrypted communication
* Centralized trust
* Standardized certificate issuance
* Improved user experience
* Better lifecycle management
* Reduced support requirements

# SecureNT vs Building Your Own Internal CA

Many organizations consider building their own Microsoft AD CS or internal CA infrastructure.

SecureNT offers:

- Faster deployment
- No CA maintenance
- No root hierarchy management
- Lower operational overhead
- Long-term certificate availability
- Simplified administration

Organizations gain the benefits of Private SSL and Internal PKI without operating a Certificate Authority themselves.

# SecureNT Certificate Hierarchy

## The Three-Level Trust Model

SecureNT uses a structured certificate hierarchy.

### Root Certificate Authority

The Root CA sits at the top of the trust hierarchy.

Responsibilities:

* Trust anchor
* Certificate hierarchy control
* Root signing authority

The Root CA certificate is distributed to client devices and becomes the foundation of trust.

### Intermediate Certificate Authority

The Intermediate CA exists between the Root CA and end-entity certificates.

Benefits:

* Improved security
* Better operational separation
* Easier certificate management
* Reduced Root CA exposure

The Intermediate CA issues server certificates on behalf of the Root CA.

### Server Certificates

Server certificates are installed on:

* Web servers
* Application servers
* APIs
* SAP systems
* Internal applications
* Development environments

When a client connects to a SecureNT-protected server, the certificate chain is validated through the Intermediate CA back to the Root CA.

# Understanding the Chain of Trust

## What Is the Chain of Trust?

The Chain of Trust is the mechanism browsers and operating systems use to determine whether a certificate should be trusted.

A SecureNT deployment typically follows this sequence:

```text
SecureNT Root CA
      ↓
SecureNT Intermediate CA
      ↓
Server Certificate
```

If the Root CA is trusted on the client device, the entire chain becomes trusted.

## Why It Matters

Without a valid chain:

* Browsers display warnings
* Applications may reject connections
* Users lose confidence
* Operational issues increase

With a properly installed chain:

* HTTPS works normally
* Browser warnings disappear
* Users experience trusted connections
* Internal applications operate smoothly

# Trust Deployment Strategy

## One-Time Deployment

Unlike public certificates, SecureNT certificates require the SecureNT Root CA and SecureNT Intermediate CA to be trusted by client devices.

This is usually a one-time deployment activity.

Once trust is established:

* Future certificates work automatically
* Additional applications require no extra client-side changes
* Certificate management becomes simpler

## Supported Trust Deployment Methods

SecureNT supports deployment through:

* Active Directory Group Policy
* Microsoft Endpoint Manager
* Mobile Device Management (MDM)
* Configuration Management Systems
* Manual installation
* Enterprise software deployment tools

# Active Directory Integration

## Why Active Directory Is Important

Many SecureNT customers operate Microsoft Active Directory environments.

Active Directory provides a centralized mechanism for distributing trust throughout an organization.

Instead of manually configuring hundreds or thousands of systems, administrators can deploy SecureNT trust certificates automatically.

Benefits:

* Reduced administrative effort
* Faster deployment
* Consistent trust configuration
* Fewer support tickets
* Improved compliance

# Group Policy Deployment

## What Group Policy Does

Group Policy automatically distributes SecureNT CA certificates to domain-joined computers.

The process installs:

### Root Certificate

Installed into:

```text
Trusted Root Certification Authorities
```

### Intermediate Certificate

Installed into:

```text
Intermediate Certification Authorities
```

After deployment:

* Chrome trusts SecureNT certificates
* Edge trusts SecureNT certificates
* Internet Explorer trusts SecureNT certificates
* Most Windows applications trust SecureNT certificates

No manual installation is required on individual systems.

## Benefits of Group Policy

* Enterprise-scale deployment
* Consistent configuration
* Centralized management
* Automated certificate distribution
* Reduced support burden

# Client Trust Deployment

## Windows

Windows provides native certificate management.

SecureNT CA certificates can be installed:

* Manually
* Through Group Policy
* Through deployment tools

Once installed correctly, Windows-based applications trust SecureNT certificates automatically.

## macOS

macOS uses Keychain Access.

SecureNT CA certificates are installed into the System Keychain and marked as trusted.

Once configured:

* Safari trusts SecureNT certificates
* Chrome trusts SecureNT certificates
* Most macOS applications trust SecureNT certificates

## Android

Android devices require manual or managed installation of SecureNT CA certificates.

Organizations frequently deploy certificates through Mobile Device Management solutions.

## Firefox

Firefox maintains its own certificate store.

Organizations may:

* Import SecureNT certificates directly
* Enable Enterprise Roots functionality

Either approach allows Firefox to trust SecureNT certificates.

# CSR Fundamentals

## What Is a CSR?

CSR stands for Certificate Signing Request.

A CSR contains:

* Public key information
* Certificate subject information
* Organization details
* Subject Alternative Names (SANs)

The CSR is submitted to SecureNT during certificate issuance.

## Why CSRs Matter

The CSR defines what the certificate will secure.

Examples include:

* Hostnames
* Internal domains
* Localhost
* IP addresses
* SAN values

Errors in the CSR frequently lead to deployment issues.

Therefore, proper CSR creation is important.

# CSR Generation Methods

SecureNT supports multiple CSR generation methods.

## OpenSSL

Recommended for:

* Linux
* Ubuntu
* Debian
* Red Hat
* macOS
* Advanced users

Benefits:

* Flexible
* Powerful
* Platform independent

## Windows IIS / MMC

Recommended for:

* Windows Server
* IIS environments
* Active Directory deployments

Benefits:

* Familiar interface
* Native Microsoft tooling

## Windows certreq

Recommended for:

* Windows Server
* Automated deployments
* Datacenter environments

Benefits:

* Scriptable
* Enterprise friendly

## Auto-CSR

SecureNT can generate the CSR automatically.

Advantages:

* Simpler ordering process
* Faster deployment
* Reduced technical requirements

Self-generated CSRs remain the preferred approach because private keys never leave the customer's environment.

# Subject Alternative Names (SANs)

## Why SANs Are Required

Modern browsers validate SAN entries rather than relying solely on the Common Name field.

Certificates without proper SAN values may generate browser warnings.

## Hostname SAN Example

```text
DNS=erp.company.local
```

## Localhost SAN Example

```text
DNS=localhost
```

## IP Address SAN Requirements

IP addresses require special handling.

For example:

```text
192.168.1.10
```

must appear as:

```text
DNS=192.168.1.10
IP=192.168.1.10
```

This is essential for modern browser compatibility.

# Browser Compatibility

After SecureNT Root CA and Intermediate CA certificates are trusted, SecureNT certificates work with:

- Chrome
- Microsoft Edge
- Firefox
- Safari
- Chromium-based browsers

Users experience HTTPS protection similar to publicly trusted SSL certificates.

# Browser Trust

## Chrome

Chrome uses the operating system trust store.

Proper installation of SecureNT CA certificates allows Chrome to trust SecureNT certificates automatically.

## Microsoft Edge

Edge follows the Windows trust model and behaves similarly to Chrome.

## Safari

Safari trusts certificates installed through macOS Keychain.

## Firefox

Firefox may require:

* Certificate import
* Enterprise Roots configuration

depending on deployment preferences.

# Troubleshooting Certificate Errors

## Certificate Not Trusted

Common causes:

* Missing Root CA
* Missing Intermediate CA
* Incorrect certificate store placement

Resolution:

Verify that SecureNT Root CA and SecureNT Intermediate CA are installed correctly.

## Connection Not Secure

Common causes:

* Incorrect SAN values
* Missing DNS SAN entries
* Missing IP SAN entries

Resolution:

Verify CSR contents and certificate issuance details.

## Browser-Specific Errors

Common causes:

* Firefox trust configuration
* Antivirus SSL interception
* Endpoint security products

Resolution:

Verify browser trust configuration and security software settings.

## Chain Validation Failures

Common causes:

* Missing Intermediate CA
* Broken certificate chain
* Incomplete installation

Resolution:

Verify the complete SecureNT certificate bundle is installed correctly.

# Antivirus and Endpoint Security Considerations

Some antivirus products inspect HTTPS traffic.

These products may:

* Intercept SSL connections
* Modify certificate chains
* Introduce trust issues

If browser warnings occur despite proper installation:

* Temporarily disable HTTPS inspection
* Verify behavior
* Create exceptions for SecureNT certificates
* Re-enable protection

Organizations should never leave endpoint protection disabled permanently.

# Operational Best Practices

## Standardize Certificate Management

Use consistent naming conventions and deployment procedures.

## Centralize Trust Distribution

Whenever possible:

* Use Group Policy
* Use MDM
* Use centralized deployment systems

## Maintain Documentation

Document:

* Certificate owners
* Certificate locations
* Expiration schedules
* Deployment procedures

## Test Before Production

Validate certificates in:

* Development
* Staging
* Test environments

before production deployment.

# Summary

SecureNT provides a practical Internal PKI solution built around a managed certificate hierarchy, centralized trust deployment, and enterprise-friendly administration.

By combining Private SSL, Intranet SSL, Active Directory integration, Group Policy deployment, structured certificate chains, and flexible CSR generation options, SecureNT enables organizations to deploy SSL/TLS consistently across internal infrastructure while maintaining operational simplicity and long-term scalability.

The final section of this knowledge base covers technical specifications, deployment scenarios, frequently asked questions, Server and Client Authentication (mTLS), industry use cases, and support resources.

# SecureNT Private SSL and Intranet SSL Knowledge Base

## Part 4 - Technical Specifications, Server and Client Authentication, Use Cases, FAQ, and Support Resources

# Technical Specifications

SecureNT Private SSL and Intranet SSL certificates are designed to provide enterprise-grade encryption and authentication for internal networks and private infrastructure.

## Default Certificate Specifications

| Parameter            | Specification                                                |
| -------------------- | ------------------------------------------------------------ |
| Certificate Standard | X.509 v3                                                     |
| Key Algorithm        | RSA                                                          |
| Key Size             | 2048-bit                                                     |
| Signature Algorithm  | SHA-256                                                      |
| Revocation Support   | CRL                                                          |
| Online Validation    | OCSP                                                         |
| Certificate Types    | Single Domain, Multi-Domain, Wildcard, Multi-Domain Wildcard |
| Validity Period      | 1 to 10 Years                                                |
| Installation License | Unlimited Servers                                            |

These specifications provide strong cryptographic protection while maintaining compatibility with modern operating systems, browsers, application servers, and enterprise platforms.

## Supported Platforms

SecureNT certificates can be deployed on:

* Windows Server
* Microsoft IIS
* Apache HTTP Server
* Nginx
* Ubuntu Linux
* Red Hat Enterprise Linux
* Debian Linux
* Tomcat
* JBoss
* SAP
* XAMPP
* VMware Environments
* Hyper-V Environments
* Private Cloud Infrastructure
* Hybrid Cloud Deployments

## Certificate Formats

SecureNT certificates are commonly delivered in:

* PEM (.cer)
* CRT
* PFX / PKCS#12
* DER

Different formats are suitable for different server platforms and deployment scenarios.

# Server and Client Authentication (mTLS)

## Traditional SSL/TLS

In traditional SSL/TLS deployments, only the server proves its identity to the client.

Example:

```text id="7z1x6j"
Browser
   ↓
Verifies Server Certificate
   ↓
Secure Connection Established
```

This model is appropriate for most internal websites and applications.

## Server and Client Authentication

Some environments require both sides of a connection to prove their identity.

In these environments:

* The server authenticates itself to the client.
* The client authenticates itself to the server.

This approach is commonly referred to as Mutual TLS (mTLS).

Example:

```text id="w4x7sj"
Client
   ↔
Server
```

Both sides present certificates before communication is allowed.

## Typical Use Cases

Server and Client Authentication may be used in:

* Internal APIs
* Government systems
* Healthcare environments
* Financial services
* Device authentication
* Manufacturing control systems
* High-security enterprise applications

## Why It Matters

Public SSL ecosystems are increasingly focused on server authentication.

Organizations requiring long-term certificate-based authentication strategies often prefer Private SSL environments where both server and client authentication can be controlled internally.

SecureNT supports these deployments while maintaining its primary focus on internal SSL infrastructure.

# SecureNT Deployment Scenarios

## Corporate Intranets

One of the most common SecureNT deployments is the corporate intranet.

Examples include:

* Employee portals
* HR systems
* Internal dashboards
* Knowledge bases
* Internal document management systems

Benefits:

* Encrypted communications
* Trusted HTTPS
* Improved user confidence

## Active Directory Environments

Many organizations deploy SecureNT certificates across Active Directory infrastructures.

Examples:

* Domain applications
* Internal portals
* Group Policy managed environments
* Internal authentication systems

Benefits:

* Centralized deployment
* Simplified trust management
* Reduced support effort

## SAP Systems

SAP environments frequently require secure communication between:

* Users
* Application servers
* Backend services

SecureNT provides practical SSL solutions for these environments.

## ERP and Business Applications

Organizations commonly secure:

* ERP systems
* Accounting systems
* Inventory management systems
* Procurement systems

using SecureNT certificates.

## Healthcare Systems

Healthcare organizations frequently deploy SecureNT for:

* Electronic medical records
* Clinical applications
* Internal patient systems
* Healthcare administration platforms

## Manufacturing Systems

Manufacturing environments often use:

* Production dashboards
* Industrial control systems
* Monitoring systems
* Reporting platforms

that require encrypted internal communications.

## Development and Testing Environments

SecureNT is particularly useful for:

* Localhost development
* Test servers
* QA environments
* Staging environments

where public SSL certificates are impractical.

# Frequently Asked Questions

## Do I Need to Provide a CSR?

No.

Customers may either:

* Generate their own CSR
* Use SecureNT Auto-CSR

Both approaches are supported.

## Can SecureNT Certificates Be Installed on Multiple Servers?

Yes.

All SecureNT certificates include unlimited server installations.

There are no per-server licensing restrictions.

## Can SecureNT Issue Certificates for Internal Names?

Yes.

SecureNT supports:

* Internal hostnames
* Internal domains
* Active Directory names
* Localhost
* Reserved IP addresses

## Can SecureNT Issue Certificates for Internal Domains That Use .com or .net?

Yes.

If the name is used internally, SecureNT can typically support it regardless of the top-level domain structure.

## Are SecureNT Certificates Public SSL Certificates?

No.

SecureNT is a Private Certificate Authority.

SecureNT certificates are intended for:

* Internal networks
* Private applications
* Closed-group environments

rather than public consumer websites.

## Can Wildcard Certificates Secure IP Addresses?

No.

Wildcard certificates secure subdomains.

IP addresses require:

* Single Domain Certificates
* Multi-Domain Certificates
* Multi-Domain Wildcard Certificates

depending on the deployment.

## What Is the Difference Between SAN and Wildcard Certificates?

SAN Certificates:

* Secure specific names
* Support IP addresses
* Support localhost
* Support mixed environments

Wildcard Certificates:

* Secure unlimited subdomains
* Simplify administration
* Do not support IP addresses

## What Validity Periods Are Available?

SecureNT certificates are available from:

* 1 Year
* 2 Years
* 3 Years
* 5 Years
* 10 Years

depending on requirements.

## What Browsers Support SecureNT Certificates?

After proper trust deployment:

* Chrome
* Edge
* Firefox
* Safari
* Internet Explorer (legacy)

and most applications will trust SecureNT certificates.

## Can SecureNT Replace Public SSL Certificates?

For internal infrastructure, yes.

For public-facing websites, publicly trusted certificates remain the preferred choice.

# Best Practices

## Use HTTPS Everywhere

Apply SSL/TLS consistently across:

* Internal applications
* Internal APIs
* Administrative interfaces
* Development environments

## Standardize Certificate Selection

Choose certificate types based on architecture rather than individual preferences.

## Centralize Trust Deployment

Use:

* Group Policy
* MDM
* Enterprise deployment tools

whenever possible.

## Maintain Certificate Records

Track:

* Owners
* Expiration dates
* Deployment locations
* Renewal schedules

## Plan for Growth

Organizations often start with Single Domain certificates and later expand to SAN or Multi-Domain Wildcard certificates as infrastructure grows.

# Support Resources

## Core Resources

SecureNT provides resources covering:

* Private SSL
* Intranet SSL
* Certificate Types
* Pricing
* CSR Generation
* Installation Guides
* Browser Trust
* Active Directory Deployment
* Troubleshooting

## Technical Documentation

Documentation is available for:

* IIS
* Apache
* Ubuntu Linux
* SAP
* Tomcat
* JBoss
* XAMPP
* Windows
* macOS
* Android
* Firefox

## Deployment Guidance

Organizations can use SecureNT resources for:

* New deployments
* Certificate migrations
* Active Directory rollouts
* Internal PKI initiatives
* Internal HTTPS standardization

# Why Organizations Choose SecureNT

Organizations choose SecureNT because they need a practical and scalable solution for securing internal infrastructure.

Key reasons include:

* Support for internal hostnames
* Support for reserved IP addresses
* Support for localhost
* Active Directory compatibility
* Internal PKI support
* Unlimited server licensing
* Long validity periods
* Flexible certificate options
* Enterprise deployment capabilities
* Strong encryption standards

SecureNT bridges the gap between self-signed certificates and public SSL certificates, providing a trusted Private SSL and Intranet SSL solution specifically designed for internal networks and enterprise environments.

# Conclusion

SecureNT Private SSL and SecureNT Intranet SSL provide organizations with a complete framework for securing internal infrastructure.

By combining:

* Private SSL
* Intranet SSL
* Internal PKI
* Active Directory integration
* Flexible certificate types
* Centralized trust deployment
* Enterprise scalability

SecureNT enables organizations to implement HTTPS consistently across internal systems while maintaining operational simplicity and long-term control.

This knowledge base covers the core concepts, certificate options, deployment practices, trust models, and operational guidance required to successfully implement SecureNT throughout internal networks and private infrastructure.

Related Guides

Additional Resources

Private SSL Guide
https://intranetssl.net/private-ssl-guide.txt

Installation and Deployment Guide
https://intranetssl.net/installation-guides.txt

Active Directory SSL Guide
https://intranetssl.net/active-directory-ssl-guide.txt