S/MIME and Office 365
-
We utilize internally signed certificates for S/MIME email encryption here, and when I arrived (and continuing to this day) the means for people to get set up for them to send a signed email out to the entire company, and the entire company replies back with a signed email. Everyone adds the certificate to their client, and life goes on. This is inconvenient, and very difficult to manage particularly when we have to invalidate a cert or one expires.
We are also on Office 365. When someone, using Outlook 2016 for Mac tries to send an email and they do not have a stored cert for the recipient a message pops up asking if they want to search Active Directory. This got me to thinking, and I'm hoping that someone here can help.
It looks like the only way to push certs to Office 365 is using AD Sync. I'd like to do that at some point, but we don't have the departmental bandwidth to set it up right now with all the potential for breakage. Is there a way to manually (using a script) to push public keys to O365? If that is not the case, is there a way to specify the search path for the cert retrieval so we can point Outlook to the local CA?
-
@Kelly Sorry, I have no idea on this one. None of my clients use certs for S/MIME
-
Did you buy your O365 from a MS Partner? If so, they should be able to submit a request for info about this to MS, hopefully helping you find an answer.
-
Getting your certificates from on-prem to O365 for users is a manual process, and probably always will be a manual process, unless you are using Azure AD Connect (formerly DirSync), as discussed on SW.
Once a user has their certificate in their local user certificate store on their computer (done via group policy AutoEnrollment), you will always need to go into the Outlook properties to select the correct certificate(s) for signing and encryption, as you already know. After that, the only way to get it to Office 365 for that user, is to hit the "publish to GAL" button there in those Outlook options where you select the certificate.
If you revoke a certificate, which I should question why it happens so frequently that it's causing you extra work, and you distribute a new one, the user (or someone in IT) will just need to go into Outlook and select the new certificate. Surely you have an easy how-to on your Intranet showing users how to do it... basically just choosing the newest one available, then hitting the publish to GAL button. (kind of the same thing if one expires)
It sounds possible that there's a way to grab the cert data from AD and push it to O365 via powershell. It's probably just a matter of knowing how to arrange the data properly for O365 to take it. I'd submit a ticket to Microsoft via their O365 Admin portal. Surely they will have more info than me.
As for your Mac users, if they do not have a domain account or a certificate on a Windows computer, you can create a Certificate for them, export it, email it to them. Then they can install it on their Mac device via Outlook for Mac. I have a separate template set up for the purpose of creating external user certificates that are outside the scope of our domain, via CertSrv (hosted on your IIS server).
*** I re-read your first paragraph (after writing all of the above), and I am now looking at it a different way. Do you mean that the only way for someone to be able to send signed emails is if everyone in the entire company FIRST sends them a signed email or something? And then everyone needs to add that person in outlook? Now sure what you mean there, but I'm sticking with all the above I wrote anyways, as that's the standard. ***
-
@Tim_G said in S/MIME and Office 365:
*** I re-read your first paragraph (after writing all of the above), and I am now looking at it a different way. Do you mean that the only way for someone to be able to send signed emails is if everyone in the entire company FIRST sends them a signed email or something? And then everyone needs to add that person in outlook? Now sure what you mean there, but I'm sticking with all the above I wrote anyways, as that's the standard. ***
Basically. I've only just started transitioning us to an internal CA service, but we are still manually generating each cert, and then installing it for any new user. That user is then instructed to send a signed email out to the entire org (only about 50 people so not absurd). Everyone in the company then replies with a signed email and we are good to go...or not. Any hiccup in that process has a lot of ripples. This is all good information though @Tim_G. Thanks for taking time to reply here and on the other site.
-
@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
