Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.


...

Note
titleWe've Moved


Please note that we've decided to move our support portal to help.savignano.net to to further improve the services for our customers.

The updated version of this page can be found at https://help.savignano.net/snotify-email-encryption/faq


Table of Contents
maxLevel2
absoluteUrltrue
stylesquare
printablefalse

...

Will S/Notify encrypt all email messages or only specific notifications?

Once activated, S/Notify will can encrypt any email message that is sent from Jira, Confluence or Bitbucket, no matter why they have been generated. However, you can configure S/Notify to not encrypt specific emails

If, due to a missing or non-matching certificate, encryption is not possible for a specific recipient, S/Notify will handle this message as configured in the Encryption Fallback configuration page (send anyway, send problem report only, or do not send at all). 

...

S/Notify enables Jira, Confluence and Bitbucket to send S/MIME or PGP encrypted emails. It can be configured to support both encryption types at the same time or just one of them, just as your requirements are. 

...

Can S/Notify help us with HIPAA compliance?

Yes. With S/

...

S/Notify follows the S/MIME 3.2 specifications with a preference for AES-256-CBC encryption, yet also supports all ciphers specified in S/MIME 4.0, including AES-GCM. If you want S/MIME 4.0 compliance for outgoing email, please contact our support desk for instructions.

Note that Java versions before Java 1.8 update 162 have only limited cryptography support. If AES-256 encryption cannot be performed because the Java runtime does not support it, S/Notify falls back to using AES-128 encryption.

For details about which Java versions support only limited cryptography and how to change that, please refer to Java Cryptography Support.

PGP

S/Notify selects the encryption algorithm based on the preferences stored on PGP key according to the OpenPGP specifications as defined in RFC 4880. If you need to override this and always use a specific cipher, please contact the S/Notify support team for instructions how to change the encryption algorithm.

Prior to version 3.2.0, S/Notify used AES-128 for PGP email encryption, because of known vulnerabilities in Triple-DES, any PHI (Protected Health Information) data in notification emails will be protected by end-to-end encryption. Encryption is an important element of HIPAA compliance, but not all forms of encryption offer the same level of security. Encrypting emails so they are unreadable by anybody or any technology is the best way to maintain the confidentiality of PHI.

Unlike Atlassian's HIPAA solution, there is no need to remove information from notification emails.

Can we use S/Notify to just sign all outgoing emails?

Yes, S/Notify can sign all outgoing emails. Signing is independent from encryption, so you can even have it just sign (and not encrypt) if you want to.

To only sign and not encrypt emails, the minimum configuration is 

  • in Encryptions Settings, under Encryption Fallback, allow unencrypted emails
  • in Encryptions Settings, under Outgoing Signature, enable signing
  • in Server Key Management, provide a keystore with the server's S/MIME certificate or PGP key

What encryption algorithm is used by S/Notify?

Please refer to our reference for details on supported encryption algorithms and how S/Notify selects which to use:

Can I temporarily suspend email encryption?

...

You can freely choose the option that is easier to handle for you. You may as well use a mixture of both options.

We want to use the SKS key server pool over HTTPS, but it fails with a certificate error. How can we fix that?

If your connection fails with something like

Error message: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

this means, that the responding server uses a certificate which has not been signed by a trusted certificate authority (CA).

Since the HKPS pool at sks-keyservers.net uses a self-signed root certificate to sign the SSL certificates of the PGP servers in the pool, you must download and import this self-signed root certificate into your your Java trust store. Please see SKS Key Server Pool for a description how to that.

Why does the connection to the key server fail, while I am sure the key server URL is correct?

...