Thread Info
  • State Not Answered
  • Replies 4 replies
  • Subscribers 0 subscribers
  • Views 920 views
  • Users 0 members are here
Options
Suggested

Exim Certificate

Deuteronium
In ASL Ver 3.202 in SMTP-Proxy-Mode a certificate
(/var/chroot-smtp/etc/exim.cert)is generated.

This certificate changes at every reboot and also with other reasons in the meantime.

To establish encrypted connections to ASL, this certificate has to be imported into the other peer in the area of trusted certificates.

The regenerations of the certificate require a continual re-importation into peers. - no reasonable work is possible.
Parents
  • 0
    Deuteronium,

    are you sure that it needs an import?
    I think the information will be exchanged
    automatically - the peer receives the needed 
    public information when it connects.

    read you
    o|iver
  • 0 in reply to oliver.desch
    Originally posted by oliver.desch:
    Deuteronium,

    are you sure that it needs an import?
    I think the information will be exchanged
    automatically - the peer receives the needed 
    public information when it connects.

    read you
    o|iver
    Exim encrypts his data with its private key. The other MTA or MUA can decrypt this data only with exim's public key. As exim create his keys by himself, no well known certification authority is  available to receive the public key. For security reasons its not so good, if any node could encrypt data and send his public key also -  everyone could pretend to be exim.
  • 0 in reply to Deuteronium
    Deuteronium,

      
     Exim encrypts his data with its private key. The other MTA or MUA can decrypt this data only with exim's public key.  
    Exim decrypts the data with its private key and
    encrypts the data with the public key of the 
    remote SMTP server. That's the way all public
    key methods operate.

    read you
    o|iver
  • 0 in reply to oliver.desch
    ok, sorry, my fault.
    But nevertheless the situation is :

    _A_ sendmail -> _B_ exim (proxy) -> _C_ ISP (relay)

    - After astaro's reboot TLS between sendmail and  exim fails:

    jupiter> tail -f /var/log/mail 
    Aug  3 18:46:30 jupiter sendmail[4000]: STARTTLS=client, relay=[192.168.101.254], version=TLSv1/SSLv3, verify=FAIL, cipher=DES-CBC3-SHA, bits=168/168

    But TLS between exim and ISP's MTA works.

    After re-copying exims certificate into sendmails   certifications folder, TLS works:

    jupiter> tail -f /var/log/mail 
    Aug  3 18:52:31 jupiter sendmail[4053]: STARTTLS=client, relay=[192.168.101.254], version=TLSv1/SSLv3, verify=OK, cipher=DES-CBC3-SHA, bits=168/168

    - I assume, sendmail accepts the exim for TLS only if he knows its certifacte.

    - My question is: why generate a new certifcate at every reboot und at every change of configuration ?  What advantage does it bring ?
    You forgive the possibility to use exim's certificate as means of authentication.
Reply
  • 0 in reply to oliver.desch
    ok, sorry, my fault.
    But nevertheless the situation is :

    _A_ sendmail -> _B_ exim (proxy) -> _C_ ISP (relay)

    - After astaro's reboot TLS between sendmail and  exim fails:

    jupiter> tail -f /var/log/mail 
    Aug  3 18:46:30 jupiter sendmail[4000]: STARTTLS=client, relay=[192.168.101.254], version=TLSv1/SSLv3, verify=FAIL, cipher=DES-CBC3-SHA, bits=168/168

    But TLS between exim and ISP's MTA works.

    After re-copying exims certificate into sendmails   certifications folder, TLS works:

    jupiter> tail -f /var/log/mail 
    Aug  3 18:52:31 jupiter sendmail[4053]: STARTTLS=client, relay=[192.168.101.254], version=TLSv1/SSLv3, verify=OK, cipher=DES-CBC3-SHA, bits=168/168

    - I assume, sendmail accepts the exim for TLS only if he knows its certifacte.

    - My question is: why generate a new certifcate at every reboot und at every change of configuration ?  What advantage does it bring ?
    You forgive the possibility to use exim's certificate as means of authentication.
Children
No Data