do-send-email-from-template in 4.7

Hello!

Does anybody know if do-send-email-from-template has been changed in 4.7
to use STARTTLS?

Asking because I'm seeing this in my trace:

Code(-9195) Error in
vnd.nds.stream://IDMDEV/System/DriverSet01/xxxxxxx/sub-etp%xxxxxxxxxxx#XmlData:360
: Couldn't send email: javax.mail.MessagingException: Could not convert
socket to TLS;
nested exception is:
javax.net.ssl.SSLHandshakeException:
sun.security.validator.ValidatorException: PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException: unable to
find valid certification path to requested target

Thanks
  • Yes, it is changed to support startTLS.

    I think this error is because engine does not yet trust the certificate used by the mail server. You would need to import the public cert into jre cacerts. By default:
    /opt/netiq/common/jre/lib/security # ls
    blacklist blacklisted.certs cacerts java.policy java.security javaws.policy policy trusted.libraries
  • On 3/12/2018 4:24 AM, sdhaval wrote:
    >
    > Yes, it is changed to support startTLS.


    Is this an option? Is there a control? Is it the port? An attribute
    to set? Config setting?

    > I think this error is because engine does not yet trust the certificate
    > used by the mail server. You would need to import the public cert into
    > jre cacerts. By default:
    > /opt/netiq/common/jre/lib/security # ls
    > blacklist blacklisted.certs *cacerts* java.policy java.security
    > javaws.policy policy trusted.libraries




  • On 03/12/2018 06:48 AM, Geoffrey Carman wrote:
    > On 3/12/2018 4:24 AM, sdhaval wrote:
    >>
    >> Yes, it is changed to support startTLS.

    >
    > Is this an option? Is there a control? Is it the port? An attribute to
    > set? Config setting?


    StartTLS is a control within the default SMTP port. This is different
    from using a TLS/SSL connection for the whole connection and is negotiated
    on the fly by the client issuing the command to switch to TLS, similar to
    what you can do with LDAP on an unencrypted port (TCP 389 by default).

    When this happens, in the middle of the established TCP connection the
    client and server then figure out certificate, if possible, and move on
    using encryption. You can test this out using the openssl s_client
    command with any old system.

    Some e-mail servers may require using STARTTLS these days, which is
    probably what happened in many cases which is why we needed this
    improvement. To test out hitting a random Google mail (MX) service you
    can test this out; adapt for your own domain by changing the 'dig' command
    accordingly:


    openssl s_client -connect $(dig short -t MX google.com | head -1 | awk
    '{print $2}'):25 -starttls smtp


    For your local MX services you may find that this has a 'return code of
    non-zero just before you start typing in the SMTP commands; this means
    your server is not trusted, so you need to setup your truststore to trust
    the CA minting the certificate, or you can get a third-party trusted cert
    and apply that to your mail service.

    --
    Good luck.

    If you find this post helpful and are logged into the web interface,
    show your appreciation and click on the star below.

    If you want to send me a private message, please let me know in the
    forum as I do not use the web interface often.
  • geoffc;2477005 wrote:
    On 3/12/2018 4:24 AM, sdhaval wrote:
    >
    > Yes, it is changed to support startTLS.


    Is this an option? Is there a control? Is it the port? An attribute
    to set? Config setting?

    > I think this error is because engine does not yet trust the certificate
    > used by the mail server. You would need to import the public cert into
    > jre cacerts. By default:
    > /opt/netiq/common/jre/lib/security # ls
    > blacklist blacklisted.certs *cacerts* java.policy java.security
    > javaws.policy policy trusted.libraries



    No. It is "opportunistic" TLS which converts a plain text to secure if the server and client support it. Uses the same port it started with. (With 4.7 a separate mail port can be specified)
    https://en.wikipedia.org/wiki/Opportunistic_TLS
    https://www.netiq.com/documentation/identity-manager-47/releasenotes_idm47/data/releasenotes_idm47.html
    "Ability to Use a Non-Standard E-Mail Port in Identity Manager Configuration"
  • On 2018-03-12 13:48, Geoffrey Carman wrote:
    > On 3/12/2018 4:24 AM, sdhaval wrote:
    >>
    >> Yes, it is changed to support startTLS.

    >
    > Is this an option?  Is there a control?  Is it the port?  An attribute
    > to set?  Config setting?
    >
    >> I think this error is because engine does not yet trust the certificate
    >> used by the mail server.  You would need to import the public cert into
    >> jre cacerts. By default:
    >> /opt/netiq/common/jre/lib/security # ls
    >> blacklist  blacklisted.certs  *cacerts*  java.policy  java.security
    >> javaws.policy  policy  trusted.libraries

    >
    >
    >

    The disturbing thing is that if breaks functionality and it is not noted
    in the docs that you need to import a certificate, since before if you
    didn't use STARTTLS the e-mail would get sent anyway, in my case it goes
    through Postfix that in turns relays to a SMTP server.
  • alekz wrote:

    > The disturbing thing is that if breaks functionality


    This feature should be optional and configurable, defaulting to "disabled" at
    least for upgrades to existing environments, IMHO.

    --
    http://www.is4it.de/en/solution/identity-access-management/

    (If you find this post helpful, please click on the star below.)
  • sdhaval wrote:

    > It is "opportunistic" TLS which converts a plain text to secure if
    > the server and client support it.


    Any way to turn this off?

    --
    http://www.is4it.de/en/solution/identity-access-management/

    (If you find this post helpful, please click on the star below.)
  • On 3/13/2018 12:24 AM, sdhaval wrote:
    >
    > geoffc;2477005 Wrote:
    >> On 3/12/2018 4:24 AM, sdhaval wrote:
    >>>
    >>> Yes, it is changed to support startTLS.

    >>
    >> Is this an option? Is there a control? Is it the port? An attribute
    >> to set? Config setting?
    >>
    >>> I think this error is because engine does not yet trust the

    >> certificate
    >>> used by the mail server. You would need to import the public cert

    >> into
    >>> jre cacerts. By default:
    >>> /opt/netiq/common/jre/lib/security # ls
    >>> blacklist blacklisted.certs *cacerts* java.policy java.security
    >>> javaws.policy policy trusted.libraries

    >
    >
    > No. It is "opportunistic" TLS which converts a plain text to secure if
    > the server and client support it. Uses the same port it started with.
    > (With 4.7 a separate mail port can be specified)
    > https://en.wikipedia.org/wiki/Opportunistic_TLS
    > https://www.netiq.com/documentation/identity-manager-47/releasenotes_idm47/data/releasenotes_idm47.html
    > "Ability to Use a Non-Standard E-Mail Port in Identity Manager
    > Configuration"


    Even better! Appreciate the response.

  • On 03/13/2018 03:14 AM, Lothar Haeger wrote:
    > alekz wrote:
    >
    >> The disturbing thing is that if breaks functionality

    >
    > This feature should be optional and configurable, defaulting to "disabled" at
    > least for upgrades to existing environments, IMHO.


    I can see why that would be,since it has always been that way, but SMTP is
    insecure out of the box, and it is way past time to changthat,
    particularly with Identity data. I suspect, or at least hope, that most
    places will have certificates associated with their servers which just
    work because they are publicly trusted (from a public CA) that is already
    in the JRE. As a result, upgrading should just improve security rather
    than causing any service interruption. I am basing this conclusion on the
    idea that in order for anybody to send e-mail to one of these servers from
    across the Internet, a trusted cert must be used (or clients must be
    misconfigured to trust anything, which is foolish), thus hopefully the
    systems that just work are in the majority.

    With that said, if mail sending fails, it may be worthwhile to have a
    policy out there that catches this and somehow deals with it (apparently
    not by sending an e-mail though). SNMP, writing some obnoxiously long
    trace message that stands out, even stop the driver (throw a fatal error).

    --
    Good luck.

    If you find this post helpful and are logged into the web interface,
    show your appreciation and click on the star below.

    If you want to send me a private message, please let me know in the
    forum as I do not use the web interface often.
  • The configuration is probably good for the majority yes.

    But is it in the upgrade documentation?
    Is it in the documentation at all?

    Great info here btw.