u/DmetaNextWeek

Shame on me for buying a wireless headset that can ONLY connect with USB - not Bluetooth or anything.

i was walking into another room with laptop in hand, usb plugged in.  The laptop made it into the room, and the USB did not - ended up bending some parts, and breaking one of the connecting prongs.  Cost of replacement is the same as buying a whole new headset, so I’m looking at repair.

Part of it is still in the board.  I bought a solder, but looking at this again I don’t know that I can do this reliably.  I might be able to pop the prong out and put in a new one.  Is there a path to repair, and what would that be?

We utilize a rather small infrastructure that requires the issuance of private certificates. We've got a standalone Enterprise Root CA, server 2019, with a Root certificate that is going to expire in a few months.

My understanding of the renewal comes from the below:

• https://learn.microsoft.com/en-us/windows-server/identity/ad-cs/renew-root-ca-certificate

My plan is to renew using the same key pair, since we don't fall under the recommended reasons to do so:

• The CA signing (existing CA key pair) is compromised.
• You have a program that requires a new signing key to be used with a new CA certificate.
• The current certificate revocation list (CRL) is too large, and you want to move some of the information to a new CRL.

I think I understand, but I've got two things that I'm worried about:

1. Domain-joined clients need to trust the root certificate. Is this automatically pushed to clients without the need to reconfigure, and does anything lose trust until this hapens?
   • I believe the answer is yes it renews, and nothing loses trust unless the root expires in the interim - If you're running an enterprise CA, the root certificate is automatically distributed within the domain. Clients receive it during the refresh of Group Policies. If you want to speed up this process, you can force a refresh using the command prompt: gpupdate /force.
2. Do certs issued by the previous root certificate require reissuance?
   • I don't believe I need to re-issue certificates generated this way, even after the original Root certificate expiration passes. I feel like that's the whole point of keeping the keys the same, but I don't see this explicitly listed anywhere.

Let me know if I'm on the right track here.

ConnectWise RMM

Starting about a month ago, we began receiving notifications from our Vulnerability Management software, Qualys, for a vulnerability for Go (go), CVE-2020-8911.  This is largely contained within C:\Program Files (x86)\ITSPlatform, which is our ConnectWise RMM installation. According to the ConnectWise RMM portal, our agent is up to date.  It appears we are running agent v5.0.3, which is listed as the current version.

• https://nvd.nist.gov/vuln/detail/CVE-2020-8911

I've opened a support case with ConnectWise, but I've already been passed to 4 people, and I believe I just got passed back to my initial tech.

Outsourcing ideas now. I don't know if there's anything to really be done, or what the real criticality of this is - I can tell you that our overall risk score is just buried under this one vulnerability. Is anyone else seeing this? Anything to be done about it?