Mail.protection.outlook.com Certificate Download
Phyllis Sterlin
Here are the two certificates from outlook.office.com, both retrieved using SSL just a few minutes ago. I got lucky and was able to get both in two separate but same requests. I have yet to capture the 2nd one from smtp.office.365.com:587 UPDATE: I finally got the 2nd one from smtp.office365.com. I hope there are only 2. I put them below.
Faced a similar issue today. I could not find a complete list of cert used by MS O365.
Closest is this Exchange Online/Office 365 SSL certificate info, but seems outdated: -us/library/mt163898.aspx
SMTP relay lets Office 365 relay emails on your behalf by using a connector that's configured with your public IP address or TLS a certificate. Setting up a connector makes this a more complicated option.
Select Domains. Make sure your domain, such as contoso.com, is selected. Click Manage DNS and find the MX record. The MX record will have a POINTS TO ADDRESS value that looks similar to cohowineinc-com.mail.protection.outlook.com as depicted in the following screenshot. Make a note of the MX record POINTS TO ADDRESS value. You'll need this later.
Unfortunately Thomas left off the part of the screen shot which explains why the certificate presented there is valid - it is because one of the subject alternate names is *.olc.protection.outlook.com which also matches the address you cited.
This isn't difficult but it's where I struggled and why I want to share.
* Configure your notification settings (Setup->Notifications->enable followups and followups via mail -> Email followups configuration
* Way of sending email -> SMTP+TLS
* Check certificate -> Yes (I guess optional but should be good practice)
* SMTP host -> your tenant SMTP host, can be found in your MX record (details in link above), should look like //your tenant address with dot replaced with hypen + .mail.protection.outlook.com//
* Port -> 25
* SMTP login and SMTP password -> Empty here you put a valid email address in your tenant
Appropriately choosing your 'Domain Restrictions' is pretty important. Restricting by IP address can be pretty not bad, but if you're in a NATed environment be careful you don't accidentally increase your scope. In my case I didn't want to put my mail relayer in our DMZ, so it was 1-to-many NATed,and I actually have a certificate I can use for this host. Those two considerations made choosing"by certificate" pretty much a no brainer.
The relayhost name is a bit odd. Office 365 always creates the DNS name for you but leaves it in the format $fqdn.mail.protection.outlook.com where any periods of your email domain in the fqdn are replaced with hyphens. That is, if secopsmonkey.com were hosted by Office 365 I woulduse secopsmonkey-com.mail.protection.outlook.com.
Once you restart postfix it will be able to connect through the connector using the x509 certificate for authentication. Now any messages sent from this server will be routed through Office 365 by wayof the connector.
Lastly, we took a deeper look at the SMTP send logs and found a discrepancy with the certificate thumbprint associated with the connection error and the thumbprint of the certificate assigned to the Exchange 2013 server.
This discrepancy appears to have been causing the mail flow issue from on premise to Office 365. With this lead, we reviewed the certificates (from the Exchange 2013 server) via the MMC in Certificates (Local Computer) > Personal > Certificates and found an expired certificate with the invalid thumbprint (40C17C1A4F34D7468D69388B7E99862DF24EC0BC). The expired certificate was then removed and an IISRESET was performed from an elevated command prompt.
What was eventually determined, is during the original run of the hybrid configuration wizard (HCW) from Exchange 2013 an older (expiring) certificate was used, then a new certificate was assigned to Exchange 2013 with the older one being removed from the Exchange 2013 EAC, and finally the HCW was run again to apply the new certificate. However, the certificate was not removed appropriately during the steps to replace the expiring certificate.
I spend a few hours on a call with Microsoft support for this very issue. In my case, I had re-keyed the certificate due to an organizational address change, but the practical outcome was the same: Exchange was using a different certificate and the thumbprint that was being used for the connectors was invalid.
2- did you download the public certificates from the SMTP server and added them to your SAS Private Java Runtime Environment certificate store? Otherwise, I see hard that the SAS JVM client will be able to handshake TLS with the SMTP server.
While I have setup a SMTP Destination in BOBJ before, and have done SSL previously using an intermediate server forwarding the request, I have not gotten it to work properly configuring it inside BOBJ itself. with SP4, the options for StartTLS and the TLS options are there to do this, as well as an option to override the default certificate location.
Copied the certificate into a certificate.crt file and placed it in a directory D:\SSL\smtp-ssl. Copied this into the win64_x64 directory where the default location is, configured the server for email-smtp.us-east-1.amazonaws.com with a port of 587 and connection Security for StartTLS with TLS version of 1.2 (verified with openssl). I also set the SMTP Certificate to: D:/SSL/smtp-ssl/certificate.crt
(destination_smtp.cpp:732) SSLCertPath: D:\SSL\smtp-ssl\certificate.crt
(opensslsocket.cpp:196) Could not load authorized certificate "D:\SSL\smtp-ssl\certificate.crt" from directory "". SSL error: error:00000000:lib(0):func(0):reason(0)
(csismtpmail.cpp:1103) Failed to connect to SMTP server: SSL negotiation has failed during setup of the SMTP server connection, please ensure your SSL configuration is correct on both the client and the server.
(destination_smtp.cpp:1440) destination_smtp: exception caught while connecting to server/sending smtp message. Details: [SSL negotiation has failed during setup of the SMTP server connection, please ensure your SSL configuration is correct on both the client and the server.].
I tried to move the certificate into the default location under win64_x64 and set the certificate path to the default variable, and got the same error message with the updated path to the certificate. I also tried to change it from StartTLS to SSL/TLS with port 465 and got the same result.
I am not sure what it means by an authorized certificate and why it shows directory as "". the certificate shows valid when opening the crt in Windows. Not sure why we need the email server certificate anyway since other tools can send SSL email without this, but that's besides the point.
I just went through dozens of hours of trying out different SMTP addresses, ports, credentials, MX records, DNS addresses, setting up connectors, creating SSL certificates and tracing messages until I found a combination that worked... Mind you this is the first time that we are using Crystal BO and all other service accounts that have ever sent out from our system used smtp.office365.com.
First, I would like to point out that we are using proofpoint as a mail filtering service and our MX records were pointing to our spam filter address, however, I found that in order to get the email system to work, you have to use the original "Point to address or value" which in our case was "ourdomain-com.mail.protection.outlook.com"
I'm trying to set up SSL over SAP BI 4.2 SP4 Patch 2 but it still showing an error regarding the certificate negociate. Does this setting works with Office 365 SMTP over SSL ? Does the SMTP relay is mandatory ?
SSL Certificates from Comodo (now Sectigo), a leading certificate authority trusted for its PKI Certificate solutions including 256 bit SSL Certificates, EV SSL Certificates, Wildcard SSL Certificates, Unified Communications Certificates, Code Signing Certificates and Secure E-Mail Certificates. We offer the best prices and coupons while increasing consumer trust in transacting business online, information security through strong encryption, and satisfying industry best practices & security compliance requirements with SSL.
We're using Office 365 direct send, so the MX endpoint address (i.e. contoso-com.mail.protection.outlook.com) with a dummy email address over port 25 and not authentication. This works fine so long as you send within your domain and have your public IP added to your SPF record, which we do. We've tried Gmail, Mailgun, and have confirmed via SMTP testers that we can send messages to the company employees. I've run packet captures during the scan and there is no traffic from the MFP. I highly suspect the scan job isn't even getting outside the machine.
Hi All
today I changed the real ip of my iredmail server and suddenly mails cannot be delivered to my office365 mail server (from iredmail to office365 ), howover I did change all the necessary settings regarding the domain and the new ip settings , here you go the mailq error :
(host centrogs-net.mail.protection.outlook.com[207.46.163.215] said: 451 4.7.500 Server busy. Please try again later. (AS780081) (in reply to end of DATA command)) .
-- 103682 Kbytes in 646 Requests.
FYI: after investigating the issue with Microsoft I had it working by adding a connector on my exchange server for iRedmail, the technician stated that there is something wrong with the mail certificate so the connector will ignore any errors.
I updated iredmail server this Friday and I did the "Fix 'The Logjam Attack'" maybe that caused this issue ??
Use these instructions to configure Outlook to use your Email Security Plus Personal ID Certificate. After importing your Personal ID certificate, you can then configure Microsoft Outlook to sign and encrypt emails.
- Encryption set-up for the e-mail addresses of your mail domain
If you decide on encrypting all addresses within your mail domain, the set-up is done in coordination with your IT contact person / provider and the IT provider for Hamburg Commercial Bank.
When setting up, your IT contact person can get in touch with our IT Service Center directly via the email adress hcob-sec...@hcob-bank.com, or you can notify your contact person at Hamburg Commercial Bank regarding the contact data of your contact person in IT. - Encryption set-up for your e-mail address only:
The necessary registration process is triggered by an encrypted e-mail, which is sent to you by an employee of Hamburg Commercial Bank.
This e-mail is initially withheld by our e-mail encryption system, and instead a registration e-mail is sent. The original e-mail is then sent after successful registration.
It can occur when the registration e-mail is received that your e-mail programme issues a warning, because the Hamburg Commercial Bank certificate contained in the e-mail is unknown to your system. Further details can be found in the following FAQ (last question).
The registration e-mail received contains information regarding the registration process, and you can choose between the alternatives listed above: - Registering online in a protected WebMail portal
By choosing the WebMail portal solution, please note that the encrypted e-mails are not made available via your own personal inbox, but rather via the secure access WebPortal of Hamburg Commercial Bank. - Encryption using own certificate or key
If you are already using an S/MIME certificate, simply respond to the registration e-mail.
If you already have a PGP key, please respond by e-mail to the registration e-mail with your public PGP key in the appendix.
Should you require assistance regarding the potential provision of a registration password, please get in touch with our IT Infrastructure Team: hcob-sec...@hcob-bank.com.