currently i'm playing with puppet in my private lab.
I've installed puppetserver and agent.
Everything looks good but could you tell me please why don't see this plus sign next to the certificates?
screen
screen2
could you tell me please why don't see this plus sign next to the certificates?
Because recent versions of puppetserver ca don't do that.
Without the --all option, puppetserer ca lists only unfulfilled certificate-signing requests, which earlier versions of the CA face would not have marked with a '+' anyway. Most of the time, there should be very few of these. In fact, there should be none most of the time unless something is wrong or the site is very busy with new node registrations.
On the other hand, puppetserver ca --all lists both unfulfilled CSRs and signed certs, but instead of distinguishing them by presence or absence of a flag character, it separates these into separate groups, each led by a descriptive heading. Since the signed certs will normally be most, and often all, of the entries, marking them with a flag character would be mostly noise.
Related
I'm trying to fix an old binary (sources unavailable of course...) that fails to connect now, probably because it's using outdated list of CAs.
However, when running through strace I don't see the binary attempting to read my CAs from /etc/ssl/certs.
Is it possible the list of CAs has been bundled into the binary itself ?
Thanks a lot,
Adam
To be clear, since you say source unavailable I assume you mean a custom program that uses OpenSSL library, since the source for the utility commandline-interface progam named openssl is still available for versions dating back to last century (and until 1.1.0 didn't change much, even when it probably should have).
Yes, definitely. A program using libssl (and libcrypto) can choose whether to use the standard file(s) for its truststore, or some other (custom) file(s) it specifies (often from configuration), or hardcoded data as you ask or data from some other source like a (secure, we hope!) database, or even no truststore at all if it uses ciphersuites that don't use certificate authentication -- anonymous, PSK or SRP -- which is rarely used but is supported by OpenSSL.
You might try strings on the program to see if they were basic enough to embed certs (and maybe other things) in PEM -- IINM that's how Lenovo Superfish was found. If they embedded binary 'DER', that still has enough redundancy you could find it, but not so easily.
Look at the network traffic with Wireshark or similar, or if you have access to the server check its logs, to see if the program is sending an alert in the range 41 to 49 in response to the server's first flight i.e. just after ServerHelloDone.
That would definitively indicate a certificate problem.
I'm after some concrete advice on how best to prevent (or at least deter) unauthorised software upgrades on an embedded system. It doesn't need to be bullet-proof and we can assume for now that the system itself is sufficiently locked down so that no-one can get unauthorised access to it.
My plan is to basically have an installer process running on the system which would receive update packages from anywhere but that could ensure those packages came from a trusted source (i.e., me) before attempting to install them.
In simple form, the update package would have the actual installation package, plus a matching digital signature that could only be generated by myself. Moreover, the signatures would be purely self-generated with no external authorities involved.
So these are my thoughts on the possible process:
Generate a private/public key pair and distribute the public key along with the embedded system itself.
When creating a software install package, pipe the contents of the package (or an MD5 of the package) through a signature generator using our private key.
Distribute the software install package along with that signature.
Have the installer check the signature against the software install package (using the public key it already has) and only install if there's a match.
If anyone can find any problems with this scheme, I'd appreciate the details, along with any specific advice on how to avoid them. In addition (though this is not the primary purpose of the question), any advice on tools to generate the keys would be appreciated.
I do not see any apparent problems with your solution. I can suggest improvements that you may have already taken into account
If the embedded software is sufficiently locked, it is not necessary to take additional measures to protect the integrity of the public key distributed with the software (e.g. by signing the installer itself and obfuscate, that could be a headache)
I've considered a TLS connection to download the updates, but it would not really needed, because packages are going to be protected with a digital signature
I suggest encapsulating the public key in an X509 certificate. This way you can control the period of validity and even a possible revocation if the private key has been compromised. In this case you will need a hierarchical Certificate Authority, with a root certificate that issues the signing certificates. Include in the truststore of the installer the public part of the root certificate. Then using a different signing certificate after expiration/revocation will be transparent to installer.
The root certificate has a long duration and a large key size (and should be conveniently secured), and the signing certificates have a shorter duration and can use a smaller key.
With this CA you could also generate a TLS certificate if you need some additional service: e.g check available updates. In this case include the certificate in the truststore of the installer to avoid man-in-the-middle attacks (SSL-pinning).
You can sign the full distribution or a hash. It does not affect security (see https://crypto.stackexchange.com/questions/6335/is-signing-a-hash-instead-of-the-full-data-considered-secure) but do not use MD5 because has extensive vulnerabilities. Use a SHA-2 function.
To generate the keys you can use openssl in command line or use the GUI application KeyStore-Explorer
I've been putting of on making my Puppet master redundant for quite a while now, but it's starting to become an issue now. So I'm starting to put this on a higher importance issue.
Although making the master itself highly available isn't much of a problem (I've already running it behind a load balancer in anticipation of making it HA).
But the problem is the CA "part" of Puppet. I guess it would be (theoretically) possible to put the Puppet master directory on a shared filesystem and have all Puppet masters use that as their storage.
But I have need for a CA for other purposes anyway, so I've been, for the last year (on and off), looking into Vault.
From the documentation and the information I've seen so far about it, it could solve a whole bunch of problems for me, not just the distributed CA part.
It can acts as a CA, but is there any way to integrate that into Puppet? As in, having Vault acts as a CA for the Puppet master(s)?
PS. Many seems to use Puppet in a masterless capacity, and that would of course negate this CA problem, but for various reasons, I don't want to do that (respect the decision please).
I have a desktop application built by InstallJammer. The application is not a problem but when it is installed on user's machine, the anti-virus on user's machine stops the services created by my application and so it stops communicating with my server. I need to get it whitelisted so that it won't be treated as a risk to the machine and the anti-virus won't stop it.
What I've known so far is
Adding a 'Publisher' to the application may help it to be treated as not risky as this process has steps of authenticating my application with a certificate. (Though I don't know if this is correct. I've refereed this link)
Googling about it I found some anti-viruses site asking me to register with my application there.
My questions:
Adding 'publisher' would serve my purpose? If yes, how would it whitelist my application?
If the above option doesn't work, do I need to get whitelisted with each and every anti-virus software product?
Answer after I achieved all that I wanted to for this.
tl;dr;
For the people directly reading the answer:
I had an installer for windows(built using InstallJammer) that creates windows services on the user's machine, which got frequently blacklisted by anti-virus programs and firewall. Also downloading it in your browser would show a message like the picture below.
Why does this occur:
This occurs because the anti-virus softwares and the firewall does not recognise your code(that is, it cannot verify that it has come from a trustworthy source). Hence it attempts to block the download or blacklist the services(services because I'm referring to my application) by stopping it or does not allow it to communicate through the network.
Solution:
You'll need to get your code verified(i.e. get your code digitally signed) by a code signing certificate(from here forward will be refereed to as CSC). These certificates are provided by Certificate Authorities(from here forward will be refereed to as CA).
Some the examples of CA(s) are : Symantec(the one that I used, because we had our SSL certificate for webapp from this CA), GlobalSign, DigiCert, Comodo, etc.)
This page shows a pricing list of CSC from different CAs.
The process to get the certificate:
This is a bit tedious process, as it has certain standards and rules to adhere to. The process of acquiring a certificate typically takes a few days. For instance, the validation process requires to fax a copy of license and a few utility bills to the Certificate Authority, for reasonable proof of my identity. They also validate phone number and there might be a need to speak to a representative.(I'm a little unsure about this process as it was done by my client back in USA).
After you get CSC:
You'll need to save the certificate as a .p12 file which will then be used to sign your code.
How to sign:
Microsoft SDK includes a the tool(signtool.exe) that can be used to sign your code (generally located at C:\Program Files (x86)\Windows Kits\8.0\bin\x86, depending upon the version of SDK installed, '8.0' can be different in our machine.
If you are a newb and have either not reached to a time where you need automation in your process of signing files(ambiguous to signing code) or have very a few files to sign(max 3 or 4) or have a lot a files to sign and are a crazy person with plenty of time, you might want to use this excellent utility provided by DigiCert that provides a really good UI(might be sarcasm) to sign and also check if your files are actually signed. Thank you DigiCert people.
How to check if your files are signed:
Of course the simplest process would be to check the properties of your file whether it contains a tab for digital signature. Other way is that Microsoft has tools that can check if your code is digitally signed, it can be found out by easy googling.
How I did my CODE Signing(automation):
For the main windows executable application that I build, it has quite some binaries and executables. So I created a batch file that does the following signing and building tasks. (I've used Microsoft's SignTool to sign the files from command line)
Asks me what environment do I want to make a build for(dev, staging or production).
Copies all those required(for build) files to a main folder.
Signs all the inner binaries and executables.
Performs an InstallJammer build from the command line itself(as I mentioned earlier, my application is built using InstallJammer). It outputs the final Setup.exe file.
And then Setup.exe too gets signed.
P.S. :
After code signing, the success and failure of your software getting whitelisted(authenticated or verified by anti-virus software and firewall) depends upon the reputation of your certificate. This reputation is determined heuristically and a good reputation means lesser chances of your application getting blocked.
Tip for Geeky people lurking out there
Try to buy a CSC subscription with a longest time period. This will help you avoid certificate rollover.
What is certificate roll over?
Certificate rollover occurs when your old certificate expires and you begin signing your code with a new replacement certificate; all of your reputation that was gained against the old certificate might be hampered, and hence there may be a time lag for your new certificate to acquire a good reputation.
So for the conditions when your CSC expires and you want to avoid mishaps, you might want to sign your software from the start using timestamp. Googling about it's(signing using timestamp) will make you 5 inches smarter.
For the people, blogs and sites that helped me throughout; more details can be found on Didier Stevens's blog.
Also a detailed explanation all about this and the mighty friend of all web developers, Internet Explorer's smart filter can be found on MSDN blog.
Scenario
I want to design a server which loads plug-in assemblies from third party vendors. The third party vendor needs to follow some contract while implementing plug-in assemblies. The third party plug-in assemblies needs to be copied to a specified deployment folder of the server. The server will dynamically load the plug-in assemblies.The server needs to load only those assemblies which are from a trusted source.
Possible Solution
As one of the solution, the server could rely on digital certificate technology. The server should load only those assemblies which are digitally signed with a trusted root certificate authority. I am planning to derive test cases from the following diagram:
The leaf node (highlighted in purple) denotes the possible test cases.
I need to get ideas/feedback on the following:
Whether the above mechanism based on digital certificates is good enough for the above mentioned scenario?
What are other alternatives in addition to digital certificate technology?
Are there any test cases missing that have not been considered (based on the above diagram)?
Thanks.
Just some random thoughts.
While not the only way to do this (off the top of my head you could for example use a HMAC with specific keys, or just a public key algorithm such as RSA or DSA on their own) it is probably the best way to achieve what you want to do with the minimum of effort.
Of course I would presume you would act as the CA in this scenario and any third-party could get a certificate signed from you? If not, and would just go for say a Verisign cert etc. you might want to consider checking the key usage and enhanced key usage fields of the certificate to ensure it is suitable for signing binaries (to stop someone for example using an SSL cert).
As pointed out in the above comment you want to check any certificate revocation lists, although that might be covered in signed versus unsigned. You probably also want a distinct test case between a file which is unsigned completely, a file which is signed but incorrectly (say public keys don't match) and one which is signed but invalidated, e.g. the signature is not timestamped by a trusted authority and the certificate has expired, or the CRL stuff.
Also are you excluding the possibility where the signing cert is the CA? It is a dumb thing to have but technically there is nothing wrong with doing so. You could even just skip the whole CA stuff and get a third party to generate their own self-signed cert and send that to the administrator of the server who would add it to the list of valid certificates for use. The only reason for the CA is they are supposed to check the details of the person who wants it, depending on how you plan to use this system than might not be necessary.