I mistakenly shared a PFX file generated by our enterprise production CA server

[-]

silence48@reddit

Can i ask what was the legitimate reason they needed to ask you for this. Are you sure you werent dealing with a phisherman?

[-]

ludlology@reddit

definitely tell your senior. he’ll be mad but he’ll be 1000x more mad if you keep it a secret

[-]

caffeine-junkie@reddit

Definitely tell. Although I wouldn't be mad at any of my juniors, I would be more like "duuuude sigh ok come here, you're going to fix it and here's how you do it."

[-]

serverhorror@reddit

Same, that's an oopsie. The scale of it is simewh between:

LOL, now go rotate the certs and add the leaked ones to the CLR and OCSP responders
Yeah, so I know this dude. A huge security freak, used PGP on all his mail. Turns out he sent his private key around for ~7 years before he realized that it works the other way around, now go rotate the certs and add the leaked ones to the CLR and OCSP responders
Really? Today of all days? Well, tough luck, now go rotate the certs and add the leaked ones to the CLR and OCSP responders

[-]

abalt0ing@reddit

It’s a CRL!!! Not a cleaner! Surprised you didn’t call it the OSCP server.

[-]

serverhorror@reddit

Lies, damn lies!

It's called

Certificate Levocation Rist

Don't you know anything?

[-]

abalt0ing@reddit

I think you’re thinking of the Certificate Levitation Risk. Honest mistake though.

[-]

serverhorror@reddit

You didn't correct any typo, it's the same wrod, isn't it?

[-]

jamesaepp@reddit

Organization - Secure, Contain, Protect?

[-]

itishowitisanditbad@reddit

Turns out he sent his private key around for ~7 years before he realized that it works the other way around

I would 100% start signing emails as him.

[-]

ludlology@reddit

Yeah, i’d be mad at having to deal with it but not at the person

[-]

L3TH3RGY@reddit

Yep. It sucks but this is what has to happen

[-]

chaoslord@reddit

Yes "having info and can mitigate" always trumps "not knowing and finding out after an attack"

[-]

etzel1200@reddit

It’s always the coverup. Not the crime.

They’ll be mildly irked. Unless you always fuck everything up it doesn’t matter. If you always fuck everything up, what’s one more thing?

If you don’t say anything that’ll get you seriously disciplined or fired at disciplined orgs.

[-]

artifex78@reddit

Jesus people, put away your pitchforks.

Vendor here. If we ask for a specific pfx, it is because we need a certificate for a system we set up for your company, and you are unable to install it yourself.

We are professionals and know how to handle private keys. It also doesn't mean we are going to steal your stuff or use it for illegal activities.

If you can't trust your vendor to do stuff for you, stop hiring them.

That being said, if you broke an internal rule and should not have provided the pfx/private key. Tell your boss, and maybe revoke the certificate in question. Do the same if you think the vendor was acting in bad faith.

Otherwise, just calm down and talk to your boss. It's not the end of the world.

[-]

LANdShark31@reddit

Why as a vendor would you need a cert signed by our internal CA?

Just use a proper DNS name and use a publicly issued one. If you don’t like the cost then integrate and use let’s encrypt.

I hate it when vendors sell naieve people in the business so called SaaS systems and then say they’ll need a VPN/ private IP space, certs, dns etc. it’s not bloody SaaS

[-]

artifex78@reddit

If it’s a system that is hosted on-prem, then you should be giving instructions for customers to do it themselves.

Sure, because that's working so well. /s

I've had clients who hosted their own CA and still didn't understand how it works or what a private key actually is.

This also applies to public certs. Many clients (and I'm talking about IT professionals here) do not understand certs and how to obtain them, let alone install them. Even though there are very good documentation and/or I showed and explained it to them. They just don't want to deal with it. I don't want to deal with theirs either, but at least I get paid for doing it.

Automation only works if someone someone is in charge of it, and that's in my case the client, not me.

[-]

LANdShark31@reddit

So you’re saying someone doesn’t know how to obtain a public cert but is capable of operating an enterprise PKI.

The process is largely the same, you’ve still got to generate a CSR. The process of getting it signed if different, then same process to install it. How can someone do one but not the other?

And it works for the vast majority of systems. I’ve never given a vendor a cert to install on my behalf. Like I say if they’re hosting it then I expect them to manage certs, otherwise it’s not SaaS. If they’re hosting we’re demoting in to help me do it (hypothetically), then I still wouldn’t be emailing them a cert. I stand by my opinion that this vendors process is flawed.

[-]

Ihaveasmallwang@reddit

Not everything needs a public cert. especially for testing.

[-]

LANdShark31@reddit

It’s quite simple

If a vendor is hosting something for me, I expect it to have a public cert so that we don’t have to be involved in the cert renewal process. If we’re hosting it on-prem then I don’t expect to have to involve the vendor in replacing the cert.

[-]

Ihaveasmallwang@reddit

It’s quite simple.

NOT EVERYTHING NEEDS A PUBLIC CERT.

And if you think you never have to provide certs to vendors, you’ve obviously never had to deal with SSO, and have probably either not been in IT very long, or been very siloed in what you do deal with.

[-]

LANdShark31@reddit

I’ve been in it 10 years. I’m not talking about SSO, besides I only supply the public key with SSO, or do you not know how it works.

I don’t care if it NEEDS a public cert, I stand by what I said. They host it, they manage certs. I host it I manage certs.

I’m sick to death of vendors selling so called SaaS which is not actually SaaS.

[-]

Ihaveasmallwang@reddit

So what you’re actually saying is that you have very little experience with how things work. Got it.

[-]

LANdShark31@reddit

You’re the one who turned it personal, not me but I’ll play the game. If you can’t handle it then do t start it.

[-]

LANdShark31@reddit

Absolutely not what I’m saying you condescending arsehole

[-]

goshin2568@reddit

I'm not denying there are use cases, but this post is specifically talking about giving a vendor a private key. When do have to do that with SSO? With e.g. SAML you're just exchanging public keys, which is totally normal, but not what this post is talking about.

[-]

Ihaveasmallwang@reddit

You’d be surprised at the number of apps that will not work without the private key and full chain.

Either way, the sky is not falling. This is a minor oops at worst.

[-]

goshin2568@reddit

Lol I've know quite a few IT professionals who handle certificates who don't have a clue how they work. They have some idiot proof documentation that says go here, download this file, stick it in this directory and name it this. They have calendar reminders for when to do it, they follow the documentation to the letter, and that's that.

[-]

artifex78@reddit

You are asking me why IT professionals I deal with don't know about the stuff they work with? How would I know? I think you are barking at the wrong tree.

I also never said anything about hosting stuff on behalf of a client. When it involves a cert, it's hosted on the client's system (on-premises) or sometimes as IaaS (which is technically also on-prem). In SaaS, there are no certs involved. I'm not an MSP.

I sometimes get a pfx as an e-mail. Against my explicit wish. Luckily, never the password together with the pfx file. Most of the time, "providing a pfx" means copying the file to the server where it's needed and providing the password by other means.

Trying to teach good security practise again and again is a waste of time with some people because they won't listen.

They usually start listening after a major incident.

People still use domain admin permission for their day to day admin stuff. Go figure.

[-]

limitedz@reddit

Its true, pretty much every other sysadmin i work with has always let me deal with certs because no one understands them.

Also when working with a vendor, I would never have a private key shared anywhere, either they send me a csr, or I'm settling up the cert myself on the web server/system in question. I don't ever see a reason to send private keys, encrypted or not.

[-]

perthguppy@reddit

The bigger question is why can’t vendors make their own PK and give me a CSR instead of making me hand over a PK. The entire point of PKI was that secrets never ever have to be shared.

[-]

melasses@reddit

I provide vendors pfx files all the time. Just as long it’s not a wildcard certificate it’s always okay.

People are to scared about rogue certificates. This is not a problem in reality. Even if a bad actor had a certificate for you domain they also need to compromise any victims DNS.

This combination has almost never happened.

Shortened certificates validity is a scam.

[-]

artifex78@reddit

DNS spoofing is a thing. Also, if your code signing cert gets comprised (at least in the past), you were in a world of shit. But there are easier attack vectors (usually the human).

The shorter lifetime is necessary because of the broken revocation system. All this crap has a nice side effect, IT is being forced to use automation, which in return results in fewer outages caused by expired certs. If implemented correctly, of course.

[-]

Sintarsintar@reddit

Code Signing has a bunch of new security requirements now

[-]

perthguppy@reddit

Yeah I don’t like trusting the client to check CRLs and honour them.

[-]

perthguppy@reddit

How often do you come accross vendors who can’t/wont give you a CSR instead of asking for a PFX?

[-]

TheDawiWhisperer@reddit

Yeah I don't get the drama here...I suspect it's the "make three envelopes" crowd that's weirdly paranoid about this.

If a vendor runs a service that needs a cert and private key and OP provided it then....so what?

As long as it's not a *.domain cert or the actual CA certificate this is fine?

[-]

Ummgh23@reddit

Soooo what if it is in fact a *.domain cert? lmao

[-]

perthguppy@reddit

OP is being vague here and could be saying that he handed over the root PK, which yeah is a fuckup, but it’s a fuckup of whoever built the rootCA and let the PK be exportable. Murphys law and all that, if someone can do something, they eventually will do that thing.

[-]

artifex78@reddit

That would have been a massive fuck up indeed.

[-]

perthguppy@reddit

If you are asking for a PFX you are idiots who don’t know how or unable to generate a CSR to give me instead. Both bad, but one ends the engagement.

[-]

artifex78@reddit

That's usually not how the conservation starts. I tell them the requirements and if a suitable certficate is already available and if not if they can provide one. The conservation then either goes in two ways a) a quick chat about FQDN and who makes the CSR or b) blank stare and asking for assistance.

Also >90% of the people I deal with don't know what a CSR is or what to do with it.

I provide a service. I know shit our clients don't know or don't want to deal with. That means I am assisting my clients in these matters. I also show them how to do it, if they are interested, in hope they will do it themselves next time.

[-]

abalt0ing@reddit

I would smack your hands hard if you asked for my pfx passwords. Hard! I’m talking Scarlet red! Bad!

[-]

perthguppy@reddit

Pffft. You can have all the PFXs you want. None of them are going to contain the PK. If you don’t know how to give me a CSR that’s not my fault.

[-]

artifex78@reddit

Battery is bad for your career. It's also seen as highly unprofessional.

[-]

Ok-Discussion5968@reddit

Attention, un certificat avec clé privée et son mot de passe est comme donner la clé de sa maison (toute proportion gardée évidemment, cela dépend à quoi sert le certificat. Pour tout objet de ce type, la dissimulation est la pire chose (= malveillance = faute grave ou lourde)

Bon, maintenant que j'ai été bien alarmiste, que faire ? 1/ demander la révocation du certificat Si l'accès est bien géré, la première chose qui doit être faite avec la présentation du certificat est de valider qu'il est toujours valide (non révoqué et non expiré). Une fois révoqué, le certificat n'est plus utilisable, et tu en demandes un nouveau. Si la révocation n'est pas testée, tu n'es pas responsable.

2/ prévenir ta hiérarchie (c'est même la première chose à faire) Car suivant le risque encouru, ils peuvent déclencher la mise en place des règles de sécurisation adaptées.

N'oublies pas, tout accès depuis Internet est un risque d'attaque potentiel ou d'accès non désiré à des données confidentielles. C'est pour cela que les sites web sont passés de http/80 (non chiffré, sans certificat) à https/443 (chiffré par certificat).

L'ingéniosité des hackers est sans limite, et quand tu penses à ce qui te semble être une petite faille, eux sont déjà en train d'éplucher tes données.

Force à toi.

[-]

hamburgler26@reddit

gif

Tell your team, learn a lesson. Not telling is way worse.

[-]

oldmilwaukie@reddit

Assuming this is for an end-entity server running a vendor-supported application and the vendor is on the hook for cert install:

The mistake here is emailing out the file and the password, this is equivalent of sharing a username and password over plain text. This can be avoided in the future by sharing the file with secure means such as secure file sharing (e.g. Citrix ShareFile or HCP Anywhere) and then providing the passphrase directly to the vendor tech responsible for install over the phone.

As someone has already stated, there are times when certs bundled with private keys need to be shared with vendors. Our org does it all the time, but we do it carefully. Sure, vendors should know how to handle private keys but not all vendors are created equal, so it’s best to gently remind them of your security practices rather than just doing what they say.

Outside of secure file sharing, if the install is occurring on your network or cloud perimeter, then an email wouldn’t be required at all, simply stage the file where install is needed and have the vendor login with an account with limited rights. Or if possible have the vendor generate the CSR for you directly on the application requiring the cert - there should be no need for a PFX or private key export in that case.

[-]

snebsnek@reddit

Oopsie poopsie. Time to rotate the certificates, it has left your control, it is compromised.

[-]

Hot-Study4101@reddit

This first, then tell of your mistake. Get assistance with this in future.

[-]

ninjaluvr@reddit

It takes 30 seconds to send a chat message to seniors and manager saying "I mistakenly shared a PFX file generated by our enterprise production CA server. Working to rotate the certs now." You should 10000% communicate this mistake immediately.

[-]

Less-Draw414@reddit

Revoke and generate a new one problem solved

[-]

AmazedSpoke@reddit

Is this the PFX cert file for a single server? Is the vendor running a load-balancer or front-end for your server? Then you're fine, they need the cert and its private key for the thing they do.

If it's the PFX and private key for the entire CA, which you would probably have to jump through a LOT of hoops to export, then it's time to start rotating.

[-]

deep_thoughts_die@reddit

I cant see a situation when someone would have the pfx of CA root lying around... Or have a reason to have it. By the sound of it its just a client cert to access the server... It probably works for bunch of servers trusting that ca root, way more than vendor is supposed to acces but still... The vendor is under nda and probably does need it for legit reasons. Yeah, they should have been issued their own and giving out your key is bad etc... But its a minor nuisance at best to crl-list it and issue 2 new ones, one for vendor and one for hapless tester.

[-]

VinceP312@reddit

Always disclose. Everyone makes a major mistake in their life in IT. It's how we learn.

[-]

Ihaveasmallwang@reddit

You’d be surprised at the number of apps that will not work without the private key and full chain.

Either way, the sky is not falling. This is a minor oops at worst.

[-]

After-Vacation-2146@reddit

Tell your team and start the revocation process. This isn’t that big of a deal so long as you address the situation in a timely manner.

[-]

gex80@reddit

Well if everything is automated, rotating the certificate shouldn't be a big deal.

[-]

jamesaepp@reddit

Your OP isn't clear.

Which PFX did you export/share? Was this a PFX and password for a CA certificate + keypair, or the PFX for what we call an "end entity" certificate + keypair (the web server you refer to)?

Ultimately, you should still escalate and communicate inside your team - treat it as a security incident, because it is. The above question simply helps narrow down how big a security incident this is.

[-]

perthguppy@reddit

At least half the blame should be on the CA team if there is one for letting a root PK be exportable.

[-]

jamesaepp@reddit

for letting a root PK be exportable

Root keys are almost always exportable. Even if you're using an HSM, backup/restore is a function that needs to be tested. The only question is what technical controls are in place to limit the ability to export.

Also ... don't assume we're talking about a root CA here. It could be an issuing CA.

[-]

perthguppy@reddit

If it’s an issuing CA it’s not that big of a drama to revoke it compared to a root CA.

And when I say exportable, I mean into a PFX with just a random password. HSMs export their PKs under wrap keys which some sysadmin isn’t going to fumble into doing

[-]

jamesaepp@reddit

And when I say exportable, I mean into a PFX with just a random password

Which is always possible. It may take extra software, but it's always possible.

https://github.com/iSECPartners/jailbreak-Windows

[-]

rileyg98@reddit

If it's out of a HSM, I would be exceptionally worried if it was "always possible".

[-]

jamesaepp@reddit

"Always possible" does not mean "unlimited".

[-]

a_wild_thing@reddit

CA team, that's a good one! Ho boy you just made my day. Sorry I am not having a dig at you, it's just that I work in the PKI space on the product vendor side and never has a customer ever had a CA team, at least so far...

[-]

iCTMSBICFYBitch@reddit

Yeah if it's just the server then it's a risk, but far smaller, and far less of a ballache to fix. Just how much of a ballache depends on change control etc but will still be the opposite end of the scale to if you've somehow shared a CA cert.

[-]

oW_Darkbase@reddit

Eh, it's just UAT and seems to be limited to an endpoint certificate. Even if it's multiple ones, it's the UAT setup. Revoke the certs, rotate them. Shouldn't be too bad

[-]

biosmatrix@reddit

Does the pfx contain the private key?

Test it:

openssl pkcs12 -info -in file.pfx -nodes

•   If it prompts for a password and shows a PRIVATE KEY block, the key is present.
•   If it only shows CERTIFICATE blocks, the private key is missing.

If the private key is missing, you’re good. If not, rotate and 🙏

[-]

perthguppy@reddit

I’m a bit rusty, but can’t you open PFXs in a text editor and see the headers of the different keys? I swear that’s what I’ve done in the past to get or check for PKs

[-]

Caldazar22@reddit

Tell your leads. They will make frustrated noises at you and then go rotate keys. And then bark at the vendor for making an inappropriate request for good measure.

[-]

SevaraB@reddit

Pretty much. My juniors would get some thankless tasks over the next week, but the vendor would get the ass-chewing from us (and legal if they decide to be uncooperative).

[-]

perthguppy@reddit

A good PKI deployment should assume vendors will try this and that no one ever should be able to export a CA PK, and that sysadmins should only be given access equal to their knowledge of PKI practices.

[-]

perthguppy@reddit

If you shared a PFX of the root, you dun goofed good.

If you shared the PFX of just any certificate you signed with the root, even an intermediate CA, no huge drama, you just need to revoke it.

If this is super critical stuff and your org allowed the CA PK to be exportable, honestly it’s on the CA team, not you, for ever having a root PK be easily exportable to a PFX

[-]

abalt0ing@reddit

There could be high drama for the downtime, especially if you’re dealing with a Web server and/or server cluster/ farm or something like that for e-commerce. Also, do this with a change request of course just like anything else, especially if mission critical or revenue generating. Definitely own it, and communicate to those with need to know. I agree though the fix is easy enough to swap keys/certs and go on about your day. And for those minimizing the issue, please leave certificates to the professionals. You should not be spilling passwords to vendors under any circumstances if you’re in charge of the PKI and the certificate distribution, and therefore their protection.

[-]

perthguppy@reddit

Yeah to be clear, not stating how to revoke it, just that it’s a simple operation that is relatively lower effort than revoking a rootCA.

[-]

TheDawiWhisperer@reddit

I'm not sure what the drama is here?

If the vendor hosts a cert with private key on your behalf to make a service then you need to give them the private key?

[-]

WarpGremlin@reddit

As someone who works in the PKI space, "CLR" makes me twitch.

If you can issue, you can usually revoke. Revoke it, tell your team you done goofed.

[-]

Mike22april@reddit

Maybe OSCP will fix that :D

[-]

abalt0ing@reddit

I had a damn seizure.

[-]

Bartghamilton@reddit

Are you sure you’re not a Project Manager? 🤣

[-]

abalt0ing@reddit

Brutal but I’m here for it!

[-]

malikto44@reddit

I have seen other people do this. One vendor kept sending me a file with the private key, another sent me the wildcard cert key for his domain.

Just make sure you tell everyone... better bitched out and have to regen them than hacked.

[-]

jorge882@reddit

Tell them. They'll be frustrated, hopefully not angry, and then they will show you how to fix it. Look at it this way...... Now you're going to learn how to rotate certs because they're going to make you be the one to replace all of the exposed certs 💯

[-]

elpollodiablox@reddit

Wait, a PFX for the root cert itself? Or just a PFX for a certificate that had been issued by the CA?

[-]

TargetFree3831@reddit

lol, such reddit

nobody cares, guys...these are good guys...vendors...there are far worse things they can do. if they host your VMware stack, you think they give a shit about a PFX? they literally own your entire businesses future...

it makes me laugh how ideologically motivated so much of IT is nowadays. the vast majority of the security landscape is complete bs smoke and mirrors. you are trusting more people than you realize with your shit.

we made fun of this in the early 2000's as well, the security push once everyone and their mother became MCSEs and needed to capitalize on their training...security firms came out of the woodwork to bolster the fear in the industry and the "expertise" all these MCSEs had...but it was the sales relationships they made at TechNet pushing new product they wanted to geek out on, not what was best for the business. but it was OK because it was all in the name of being more secure. doesn't every company want to be more secure!?! how could you possibly question that??

McAfee didn't get rich because he had the best product, that's for sure..

its ok, not even a blip on the radar. Just let them know and trust me, you will fuck up FAR worse than this. all good 👍

[-]

Appropriate_Web_2320@reddit

Genuine question, assuming this has its own private key and fqdn for this use case why is it bad?

[-]

DarkwolfAU@reddit

Errr…. So? Assuming it was a leaf certificate with CA: FALSE set, the amount of damage that can be done by it is very limited, and presumably you trust your vendor enough to not treat it like you posted the key on reddit.

If it’s really that much of a problem, rotate the key on the UAT box and revoke the old cert.

But what you mustn’t do is keep it secret. Just mention it to a senior. Odds are they won’t care.

If it was a certificate without CA: FALSE, you’re in trouble…

[-]

VictorZ678@reddit

Tell your senior and revoke it from CA and request the client to delete it from his system(s) / email.

[-]

BoxOk5053@reddit

The fact you didn't think twice to maybe ask your senior lmao

Thus sub has the stupidest PKI related incidents reported I swear.

[-]

Recalcitrant-wino@reddit

Tell your senior and have him re-key it.

[-]

Affectionate_Ad_3722@reddit

telling the senior sys admin and my team leader about this, or just tell the vendor to delete it and never use it.

Both. You do both. Immediately. You fucked up, admit it straight away while fixing it.

Everyone fucks up, we're not robots. If your boss doesn't back you when you hold your hands up as soon as it happens, get a new boss.

Life's too short to work for people who don't have your back.

[-]

kerubi@reddit

Not enough info. So you just a single cerificate with a unique key? This might be just what was expected. The vendor would need to have the key to be able to use the certificate.

[-]

LANdShark31@reddit

Own it. Never cover up your mistakes, if you do and get caught and you will get caught then your seniors will never trust you.

Someone in my team nearly got sacked for taking down the prod internet. The thing is we weren’t considering it because they broke prod internet, we were considering it because they didn’t immediately tell me. They told someone else in the team who correctly advised that they needed to hang up and tell me what they’d done so we could fix it quicker.

Besides it’s hardly crime of the century, it’s not like you sent the root cert. Just revoke the cert and move on.

[-]

SirLoremIpsum@reddit

I'm now stuck between telling the senior sys admin and my team leader about this, or just tell the vendor to delete it and never use it. What should i do?

Always own up and discuss with your team.

It's Always the coverup that gets you from "dude makes mistakes but we can train him" to "dude is a liability and we need to fire him".

Tell both of them asap.

Even if the vendor said "yup it's deleted all good". It's not all good.

Own up. Learn the proper way. Do the needful tk rotate stuff on your end.

It's a learning opportunity and you will build good will amongst your team as someone trustworthy.

[-]

1fatfrog@reddit

Own it and you'll be respected after the issue has been resolved. Hide it or delay the reveal and it will destroy your credibility. Bad news is like milk, not wine. It does not get better with age.

[-]

mkosmo@reddit

The key should be considered compromised by the vendor. Is that a big deal? I couldn't tell you. There are cases where it is and cases where it isn't. Talk to your team.

Shit happens. It's really not a big deal either way. It's a teachable moment either way, too.

[-]