S/MIME and Office 365
-
@Kelly For digitally signing emails, it's definitely not supposed to work like that. You should be able to send a digitally signed email to anyone in the world at any emails address. And as long as their email client is capable of reading certificates, such as Outlook, Thunderbird, or OWA, then (basically) they will see a red ribbon saying it's signed and all is well.
Now if you are encrypting emails, within an organization using a Windows AD Domain and Enterprise CA, it should work the same way..... But, if you want someone outside the organization who has nothing to do with you (the outsider), to send one of your users an encrypted email, your user will need to send them a signed email first, so the outsider can use your users public key to encrypt the email (in Outlook by adding your user to their contacts list), where your user will use their private key to decrypt it once they get the email. This is normal and no other way to do it.
What I am understand now from you, is that internal users sending signed emails to each other within your organization, it's as if they are all outsiders sending encrypted emails as described above.
If that's still the case and I'm finally correctly understanding your issue, could you take the time to describe and lay out how everything is set up so I can try and see what's wrong? Perhaps then I can guide you on setting it up a little differently so it will work as expected or as it should.
-
@Tim_G Not exactly. We have the trust chain working fine. The pain point is in having access to other internal users' public keys and the distribution thereof.
We generate user certs, install them and our internal root and intermediate certs on the individual's computer (mostly Macs running Outlook 2016). The user will then send out a signed email to all and everyone will reply back with a signed email in return. This gives everyone the digital signature of the new employee and distribute the new employee's digital signature to everyone else. Now users are able to encrypt messages to the new employee and the new employee can encrypt messages to anyone in the organization.
My goal is automate and centralize as many portions of this as I can.
-
@Kelly Maybe the problem is your Global Address List (GAL), or you simply aren't waiting long enough.
Let me try a run-through here:- User joins the company.
- O365 email account is set up for new user.
- New user logs on to new Mac computer, sets up Outlook.
- IT Admin sends new user his/her certificate via email (or by whatever means). Preferably a .PFX so it contains private key and whole CA chain.
- New user or IT admin goes into new users Outlook trust center/email security settings to set signing/encryption certificate(s).
- While still in Outlook Email Security settings, "Publish to GAL" button is clicked, success confirmation pops up.
- After 24 hours, or via users manually updating their Address Book in Outlook, users are now able to send encrypted emails to new user.
Basically, when you publish to GAL, it's loading all certificate information to O365. Every else's address books will automatically update I think the default is once per day. So if users can't send the new user encrypted emails, they either need to update their address book in Outlook, or simply wait a day or so. As long as they are all part of the same organization in Office 365, they'll share the GAL and get the same one.
-
@Tim_G said in S/MIME and Office 365:
@Kelly Maybe the problem is your Global Address List (GAL), or you simply aren't waiting long enough.
Let me try a run-through here:- User joins the company.
- O365 email account is set up for new user.
- New user logs on to new Mac computer, sets up Outlook.
- IT Admin sends new user his/her certificate via email (or by whatever means). Preferably a .PFX so it contains private key and whole CA chain.
- New user or IT admin goes into new users Outlook trust center/email security settings to set signing/encryption certificate(s).
- While still in Outlook Email Security settings, "Publish to GAL" button is clicked, success confirmation pops up.
- After 24 hours, or via users manually updating their Address Book in Outlook, users are now able to send encrypted emails to new user.
Basically, when you publish to GAL, it's loading all certificate information to O365. Every else's address books will automatically update I think the default is once per day. So if users can't send the new user encrypted emails, they either need to update their address book in Outlook, or simply wait a day or so. As long as they are all part of the same organization in Office 365, they'll share the GAL and get the same one.
No, we're not doing anything from 6 on. There is no "Publish to GAL" button in Outlook for Mac. This is why we're distributing the public keys manually.
-
@Kelly said in S/MIME and Office 365:
@Tim_G said in S/MIME and Office 365:
@Kelly Maybe the problem is your Global Address List (GAL), or you simply aren't waiting long enough.
Let me try a run-through here:- User joins the company.
- O365 email account is set up for new user.
- New user logs on to new Mac computer, sets up Outlook.
- IT Admin sends new user his/her certificate via email (or by whatever means). Preferably a .PFX so it contains private key and whole CA chain.
- New user or IT admin goes into new users Outlook trust center/email security settings to set signing/encryption certificate(s).
- While still in Outlook Email Security settings, "Publish to GAL" button is clicked, success confirmation pops up.
- After 24 hours, or via users manually updating their Address Book in Outlook, users are now able to send encrypted emails to new user.
Basically, when you publish to GAL, it's loading all certificate information to O365. Every else's address books will automatically update I think the default is once per day. So if users can't send the new user encrypted emails, they either need to update their address book in Outlook, or simply wait a day or so. As long as they are all part of the same organization in Office 365, they'll share the GAL and get the same one.
No, we're not doing anything from 6 on. There is no "Publish to GAL" button in Outlook for Mac. This is why we're distributing the public keys manually.
I did not know that. I'm not as familiar with Outlook on Macs. What percentage of users use Outlook on a Mac?
When I get some more time, I'll take a look at some things and get back to you. -
Could your mac users do a setup on a windows machine just to push this, then move to their mac?
-
@Dashrender said in S/MIME and Office 365:
Could your mac users do a setup on a windows machine just to push this, then move to their mac?
It is possible, but I'm trying to simplify the process...
-
I don't know certs in Exchange at all - so don't crusify me for asking.
How are your certs created? a cert server on your local network? If yes, are they used for other domain level things? If no - does MS have any solution inside O365 that can create these certs and keep it all inside O365? I thought they had security stuff inside O365, but really know nothing about it.
-
@Dashrender said in S/MIME and Office 365:
I don't know certs in Exchange at all - so don't crusify me for asking.
How are your certs created? a cert server on your local network? If yes, are they used for other domain level things? If no - does MS have any solution inside O365 that can create these certs and keep it all inside O365? I thought they had security stuff inside O365, but really know nothing about it.
They've been created using OpenSSL on a stand alone system. Due to regulatory requirements we cannot store private keys in O365, so even if those systems existed we couldn't make use of them.
-
@Kelly said in S/MIME and Office 365:
@Dashrender said in S/MIME and Office 365:
I don't know certs in Exchange at all - so don't crusify me for asking.
How are your certs created? a cert server on your local network? If yes, are they used for other domain level things? If no - does MS have any solution inside O365 that can create these certs and keep it all inside O365? I thought they had security stuff inside O365, but really know nothing about it.
They've been created using OpenSSL on a stand alone system. Due to regulatory requirements we cannot store private keys in O365, so even if those systems existed we couldn't make use of them.
aww.. ok.
-
@Tim_G for your reference, here is what I see on my MacBook. I am not using Certificates.
-
@JaredBusch Thank you
