This topic contains 5 replies, has 2 voices, and was last updated by
October 21, 2015 at 11:11 am #31120
In about a month the first truly free signing solution promises to revolutionize SSL (and hopefully my scripts) the way we know it. Hoping it's all it's cracked up to be....
Can the community comment on how this might allow folks like myself who would like to run scripts and deploy modules on multiple environments in a safe, best-practices way?
Also I think it would be good to have a tutorial on how to implement script signing easily and with minimal hassle and research.
October 21, 2015 at 12:25 pm #31124
Well, first of, people will need to trust the certificates issued by them – which isn't going to happen automatically. Second, they're issuing SSL certs. That's different from a code-signing cert. You can't use an SSL cert at all to sign code. So I guess my comment would be, "this doesn't matter to you."
To take your third point, you just run Set-AuthenticodeSignature in the shell. It's pretty low-hassle. You can read "about_signing" in the shell if that doesn't qualify as too much research.
Code signing isn't about encryption. It's about trust. It's about your code being marked as coming from you, and being guaranteed to be exactly the code you wrote – nobody can modify it without breaking the signature. But it does require a code-signing cert, which is traditionally a higher barrier of acquisition than an SSL cert, because the CA has a huge burden of responsibility in accurately verifying your identity. Also, code-signing certs are issued to organizations, not people.
October 21, 2015 at 12:43 pm #31125
OK thanks, and excuse my ignorance with this. So this announcement doesn't concern coding certs whatsoever? (I don't see anything, but it's harder to prove a negative)
What would be the procedure to implement a code signing cert for multiple domains? When I looked into this previously I stopped pursuing it for the fact that there was a cost needed to get a cert, which was needed if you wanted to do things outside your local network.
I can create my own cert for my domain. I can then copy that cert to several other domains (?–stop me if I'm wrong). How could I deploy it to 500 domains? (general tips good enough, don't re-write the book).
October 21, 2015 at 12:55 pm #31126
Code signing certs aren't issued to a domain. They're issued to a company or organization. So... you just buy one. Yes, they're expensive, but that's because of the extensive identity verification process involved. And if you just issue your own code-signing cert, it's useless, because nobody will trust it. Presumably you already trust your own code, so there's no reason for you to sign your code unless you're sharing it.
You're thinking "domains" as in SSL certs. That's not how code signing certs work. This isn't really the best forum to go into a discussion on different cert types, but almost everything you know about SSL certs isn't applicable to code signing certs.
You would never copy your cert to other domains or computers. Anyone running signed code needs to trust the Root Certification Authority that issued the certificate – but they do not, under any circumstances, get your actual certificate. So there's no "deployment." There's no "domain."
Unfortunately, I think this might be something you have to research a bit more ;). Microsoft's MSDN Library has extensive information on code signing, for example.
October 21, 2015 at 1:01 pm #31127
Sorry to use that word and cause confusion. I meant domains as in local domain, like in an Active Directory mindset. But I see your point. thanks.
October 21, 2015 at 1:49 pm #31129
And you also wouldn't deploy based on AD domain. Now, if you were using some kind of off-brand CA, then you might need to use GPO to deploy that CA's root certificate, making it trusted by the computers that would run your code. That's obviously a per-domain activity, since GPOs are per-domain.
For example, when companies stand up their own CA, it's really common to use a GPO to deploy the company root cert to the company's computers.
The topic ‘Let's Encrypt November 16’ is closed to new replies.