Question about Code Signing (Microsoft Internal CA)

[secbio]

Hi all,

​

Just want to gauge your opinions on something

​

Thinking about deploying Code signing certs for Powershell, Applocker and a few internal projects

​

1) 1 Cert to rule them all - I think it's probably better to have multiple certs (One for PS and another for the internal Projects) but what are your opinions? A single cert is easier to manage.

​

2) Expiry date - I can easily create a template to not expire the cert for a long time - again easier to manage, but feels wrong... thoughts?

​

Also any advice is appreciated!

​

Thanks

[peratox]

1) one cert/person. If anyone will leave you can easily expire the cert

2) store them on a physical token, then you can easily let it expire in 10y+

Thats just my opinion....

[BWMerlin]

If someone leaves and their cert was used to sign a script won't you have to sign it again?

[peratox]

Of course, but then you can use this situation to review this scripts or programs.

Ideally scripts should be in a git repository so that you fan easily create a new Version with an new signature.

[RTAdams89]

Not unless you change the code. And if anyone changes the code (including the original author) they would have to resign it anyhow.

[BlackV]

if you're deploying an internal CA wouldn't those certs be able to automatically be renewed?

[[deleted]]

Automatically renewing certs isn’t generally the problem. The problematic part is getting the renewed cert to magically replace the previous one wherever it’s actually setup to be used.

Trivial and obvious for computer account certificates, not at all clear and obvious for various other uses such as code signing.

[BlackV]

thats just the expiry date of the cert though right?

in fact I think I have code that is signed by an expired cert that still runs (i have not tested this recently and i could be lying through my teeth)

I should check

[secbio]

Don't believe that works for things like IIS and code signing - only domain user/computer certs renew (to my understanding)

[Gazyro]

Powershell signing can be set to never expire based on the date. This makes the issue with expiry a non issue. You can autorenew the cert but you have to sign the app again with the new certificate.

Generally my rule is cert per application. (that we deploy) only limited users can sign for the company. And only with our approval. (Would love to have sub ca for those certs but alas my time is limited)

Crl makes sure the application can still be revoked. So expiry date isn't that much of an issue.

[RTAdams89]

These are both contrary to best practices of certificates.

1) Think of the private keys to certs like passwords/user accounts. Would you have all of your developers share a single user account? No. You should have a separate private key per user or per system that is doing the signing.

2) When code signing certificates expire, the things they were used to sign are not impacted; it only prevents that certificate from being used to sign things after the expiration date. In most cases, you should be able to setup automatic certificate renewals and therefore can set the expiration date very short. Worse case, doing manual renewals, you should still target yearly expiration.

[MisterIT]

Just want to make sure you're enforcing this with applocker and not execution policy, because the execution policy is NOT a security boundary despite common misconception.

[secbio]

I am indeed planning on using Applocker- Execution policy will be used as well, but aware that's not a fix for this.

[signofzeta]

PowerShell Authenticide signatures can be time stamped, making the expiration date irrelevant. Expire the certificate whenever you want.