Trustwave SpiderLabs Exposes Unique Cybersecurity Threats in the Public Sector. Learn More

Trustwave SpiderLabs Exposes Unique Cybersecurity Threats in the Public Sector. Learn More

Services
Capture
Managed Detection & Response

Eliminate active threats with 24/7 threat detection, investigation, and response.

twi-managed-portal-color
Co-Managed SOC (SIEM)

Maximize your SIEM investment, stop alert fatigue, and enhance your team with hybrid security operations support.

twi-briefcase-color-svg
Advisory & Diagnostics

Advance your cybersecurity program and get expert guidance where you need it most.

tw-laptop-data
Penetration Testing

Test your physical locations and IT infrastructure to shore up weaknesses before exploitation.

twi-database-color-svg
Database Security

Prevent unauthorized access and exceed compliance requirements.

twi-email-color-svg
Email Security

Stop email threats others miss and secure your organization against the #1 ransomware attack vector.

tw-officer
Digital Forensics & Incident Response

Prepare for the inevitable with 24/7 global breach response in-region and available on-site.

tw-network
Firewall & Technology Management

Mitigate risk of a cyberattack with 24/7 incident and health monitoring and the latest threat intelligence.

Solutions
BY TOPIC
Offensive Security
Solutions to maximize your security ROI
Microsoft Exchange Server Attacks
Stay protected against emerging threats
Rapidly Secure New Environments
Security for rapid response situations
Securing the Cloud
Safely navigate and stay protected
Securing the IoT Landscape
Test, monitor and secure network objects
Why Trustwave
About Us
Awards and Accolades
Trustwave SpiderLabs Team
Trustwave Fusion Security Operations Platform
Trustwave Security Colony
Partners
Technology Alliance Partners
Key alliances who align and support our ecosystem of security offerings
Trustwave PartnerOne Program
Join forces with Trustwave to protect against the most advance cybersecurity threats
Loading...
Loading...

INFO: What information do I enter in TLS wizard when I am creating a certificate signing request to send to a certificate authority?

Expand / Collapse


This article applies to:

  • Trustwave MailMarshal (SEG)/SEG
  • Transport Layer Security (TLS) functionality

Question:

  • What information do I enter in TLS wizard when I am creating a certificate signing request to send to a certificate authority?
  • What is the Common Name for a MailMarshal TLS certificate?

Information:

Most fields in the TLS wizard are self explanatory or explained in the Help.
The Common Name and Alternative Names are particularly important and the required information can differ depending on the environment.

Common Name

  • In all cases, the Common Name should be the fully qualified host name of the machine where you are creating the certificate (such as mailserver.mycompany.com). This is often the server name and domain name from Windows properties, but it could also be the Server Host Name set in the Mail Server Properties > Advanced (for each processing server).
  • Load balanced or Round robin DNS: If you have multiple processing node servers accepting messages under the same DNS name, all servers have the same Common Name. You should run the TLS wizard only on one server, request and install one certificate, then export/import it (or copy it) to the other servers.
  • Differing MX records: In an enterprise scenario where multiple processing nodes accept mail under different DNS names, you can use a separate certificate for each node. You could create a certificate signing request on each of the nodes. Each certificate should use the external DNS name of the specific server as its common name.
    • In versions of MailMarshal SMTP/SEG that support Alternative Names (SAN), you can use the same certificate for all nodes by entering the alternative name information as described below.

Alternative Names

  • Where an installation accepts email for multiple domains, you should enter each domain (not FQDN) in the Alternative Names field of the wizard (one per line).
    • For example:
      example.com
      sub.example.com
      example2.com
  • Where an installation includes more than one processing server, you should include the FQDN of each server in the Alternative Names.
    • For example:
      mail1.example.com
      mail2.example.com

Note:

  • In all scenarios you might need to use chained certificates as described in the related articles linked below.
  • Alternative Names (SAN) are supported in version 7.0 and above.

To contact Trustwave about this article or to request support:


Rate this Article:
     

Related Articles



Add Your Comments


Comment submission is disabled for anonymous users.
Please send feedback to Trustwave Technical Support or the Webmaster
.