Thread Info
  • State Suggested Answer
  • Locked Locked
  • Replies 3 replies
  • Answers 2 answers
  • Subscribers 3 subscribers
  • Views 1713 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Certificate Chain of Trust problem using SMTP Proxy with UTM 9

westpj

Hello Guys,

I'm currently experiencing some problems regarding certification and Chain of Trust.

A business partner is going to introduce a new policy forcing any communication between parties' mail servers to use "Mandatory TLS".

They require certificates of an official CA and complete Chain of Trust.

We are running UTM 9 with SMTP Proxy enabled.

The Firewall has an FQDN Hostname set (fw.domain.local), so I can't register it as SAN (AFAIK) and therefore can't ensure the Chain of Trust.

Testing the TLS will always show errors because fw.domain.local has no public signed certificate. Although TLS is working fine the domain couldn't be verified.

My certificate is registered on mail.domain.com and the DNS entry points to the WAN Gateway of the UTM.

 

I would be very grateful for help and excuse if I selected the wrong group or something.



This thread was automatically locked due to age.
  • 0

    Your internal FQDN does not matter..

    Assume your published DNS name for MX is mx.example.com

    1. You need to buy a certificate with one of these, in PFX / PCKS12 format:
      • mx.examplec.com as the only name
      • mx.example.com as a SAN, or
      • *.example.com as a wildcard.

    2. You need to configure mx.example.com as the host name in Email Protection.. SMTP... Advanced Tab,   Advanced Settings section.   This is the helo/ehol name issued during connection startup, and it is best practice for it to match with your DNS name.

    3. You need to load the certificate chain into UTM:
      • Management... HTTPS Certificate... import CA Certificate (recommended), or
      • Webserver protection... Certificate Management.

    4. Publish the new internal name in your DNS.   Assuming your internal network is example.local, this requires a bit of a trick:
      • Create a new ZONE called mx.example.com
      • Create a default record for the zone (A record with no name), and assign the internal IP address of your UTM.
      • mx.example.com will now resolved to your internal address using your internal DNS.   All other example.com names will resolve to public addresses using an Internet DNS lookup.

    Teach your users to use the new (fully qualified) name and reconfigure your internal connections to use the new name, so that nobody gets certificate errors.   (Unqualified names will fail certificate checks.)

  • 0 in reply to DouglasFoster

    Thanks for your reply!

    The problem is that the SMTP Hostname is already correctly configured. 

    I tested the protocol (using a public service) with a self-signed certificate ( configuration exactly as you stated) but the test shows the FQDN of the firewall and that it doesn't match the CN or SAN...

    Everything is set as you stated except the DNS thing. To be clear, in 4. you mean a forwarding zone? Could you explain the purpose of that?

    Or is there something I'm not getting here?

  • 0 in reply to westpj

    The main problem is because you are using a self-signed certificate.   You are also assuming that the certificate has to match the device's configured hostname, which is not true.   The certificate only has to match the host name published in the DNS system used by the client web browser.

    UTM does not provide a way to generate a certificate signing request.   I do this on Windows using the command line utility.   First use notepad to create a CertRequest.Inf file, similar to the example below.   You need to edit the Subject line.

    [Version]
    Signature="$Windows NT$

    [NewRequest]
    Subject = "CN=hostname.example.com, OU=MyDept, O=My Company, L=My City, S=MyState, C=US"
    KeySpec = 1
    KeyLength = 2048
    ; Can be 1024, 2048, 4096, 8192, or 16384.
    ; Larger key sizes are more secure, but have
    ; a greater impact on performance.
    Exportable = TRUE
    MachineKeySet = TRUE
    SMIME = False
    PrivateKeyArchive = FALSE
    UserProtected = FALSE
    UseExistingKeySet = FALSE
    ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
    ProviderType = 12
    RequestType = PKCS10
    KeyUsage = 0xa0

    [EnhancedKeyUsageExtension]
    OID=1.3.6.1.5.5.7.3.1 ; this is for Server Authentication

     

    This example does not use a SAN clause for additional names.   I think the syntax is SAN=fqdn1, fqdn2, but I can hunt up a file that I have used with that syntax if you need it.

    Use this command to generate the certificate request

    CertReq -New certrequest.inf certrequest.txt

    Use the TXT file contents to buy your certificate.   When the response is received from the CA, accept it into your Windows PC with this command:

    CertReq -Accept responsefile

    Then export it out of Windows with the option to include the private key and the full certificate chain into a PFX file with a password.   Import the PFX file into UTM and activate it for at least SMTP.   I use a single certificate for both WebAdmin and SMTP.  After everything is stable, delete the certificate from your Windows PC but keep the PFX file in a secure place and document the file password.

    Note that the certreq commands can be used on any PC with any hostname.   Also note that the completed certificate can be loaded onto multiple PCs, as long as the private key is included.   Being able to do this is important for load sharing webservers and for WAF.  The request file determines the certificate name, not the device on which it is run.  IIS, and other environments, may provide a certificate request process which makes assumptions, but those assumptions are not required.

Unfiltered HTML