Is there a way to check a certificate is signed by a given root certificate using SecureTransport API similar to OpenSSL X509_verify?
On OS X, the API to create and manipulate certificates is the Certificate, Key, and Trust Services:
Certificate, Key, and Trust Services is a C API for managing
certificates, public and private keys, symmetric keys, and trust
policies in iOS and OS X. You can use these services in your app to:
Create certificates and asymmetric keys
Add certificates and keys to
keychains, remove them from keychains, and use keys to encrypt and
decrypt data
Retrieve information about a certificate, such as the
private key associated with it, the owner, and so on
Convert
certificates to and from portable representations
Create and
manipulate trust policies and evaluate a specific certificate using a
specified set of trust policies
Add anchor certificates
See for example:
SecTrustCreateWithCertificates - Creates a trust management object based on certificates and policies.
SecTrustEvaluate - Evaluates trust for the specified certificate and policies.
SecTrustSetAnchorCertificates - Sets the anchor certificates used when evaluating a trust management object.
Related
I saw there are two type of certificate which is elastic-stack-ca.p12 and elastic-certificates.p12. What are the differences between these two certificate.
https://www.elastic.co/guide/en/elasticsearch/reference/current/security-basic-setup.html#generate-certificates
Also I noticed we have HTTP certificate
https://www.elastic.co/guide/en/elasticsearch/reference/current/security-basic-setup-https.html#encrypt-http-communication
why there are so many certificate.
If I want to send data from beats which certificate should be used? I saw it need .cer and .key
can someone help me to understand this.
You need both, and each one has a specific role.
***ca.p12 is the certificate to the new Certificate Autohirity which is created since Elastic certificated is auto assigned.
***certificate.p12 is the certificate to each single instance of your elasticsearch cluster.
I would recommend you to follow the steps here https://www.elastic.co/guide/en/elasticsearch/reference/current/security-basic-setup.html
Source:
https://www.elastic.co/guide/en/elasticsearch/reference/current/certutil.html#certutil-ca
ca.p12 -> CA Mode
The ca mode generates a new certificate authority (CA). By default, it produces a single PKCS#12 output file, which holds the CA certificate and the private key for the CA. If you specify the --pem parameter, the command generates a zip file, which contains the certificate and private key in PEM format.
certificates.p12 -> Cert Mode
The cert mode generates X.509 certificates and private keys. By default, it produces a single certificate and key for use on a single instance.
To generate certificates and keys for multiple instances, specify the --multiple parameter, which prompts you for details about each instance. Alternatively, you can use the --in parameter to specify a YAML file that contains details about the instances.
We use Advanced Installer and at the moment we sign the .exe and installer package with a Standard Code Sign Certificate for token using a Safenet USB token. We want to move to the cloud and use Azure Key Vault there. Azure Key Vault needs a HSM certificate and we need to buy a new one. Is it possible to switch from token to HSM and will the old deployed Windows Services signed with the token certificate accept new update packages signed with the new HSM certificate?
As far as I understand it, the private key is stored on the usb token and we can't get it, so HSM will use a new private key?
We use GlobalSign certificates.
There should be no problem if you switch to a new certificate.
The only case you should be aware of is if you use the Install only digitally signed update packages signed with the same certificate as the Updater option from the Updater view of your setup project. Check this article.
When you use the Updater feature with this option enabled you should make sure that the new certificate has exactly the same subject as your old one.
Keychain access - >certificate assistant -> request a certificate from a certificate authority -> save to disk -> save as .certSigningequest
Does not generate a public/private key chain, when I go to keys.
How do I solve this, thanks
Request a certificate from a certificate authority creates a Certificate Signing Request, not a public/private key chain. It will create the private key and store it in your key chain (as you named it), but the purpose of that command is to allow you to request a full X.509 certificate from an external Certificate Authority.
If you need to create just a public/private key pair, then it depends a bit on what you are planning on using it for. For example, you can create an SSH public/private key pair by using ssh-keygen.
Similarly, you can create an RSA public/private key pair using the commands from this answer from the security forum.
If, on the other hand, you're actually trying to create your own certificates, not just the public/private key pair, you can use Keychain Access to create a self-signed certificate using the Create a Certificate command. That will contain the signature of your self-signed CA and the public key.
Is it different from any other certificate I can generate via makecert or buy from some authority?
As mentioned by Mile L and Boot to the Head the Extended Key Usage is what determines the purpose that the key can be used for.
Most commercial certificate authorities (Verisign et al) issue certificates for single purposes, or for as few as possible.
They use this narrowing of the puropse to carve out different markets for the certificates and then price them accordingly.
You see them selling different Object Signing certs for Windows Assemblies / Java / Office / Adobe Air etc when (in most cases) the resulting certificate is the same.
For example the Comodo codesigning cert issued here can sign Java applets, WebStart applications, Firefox extensions and even Windows assemblies.
The certificate that's used to sign software is the same certificate that would be used to sign any document. What's different about signing software is where the signature finally resides. In a typical document signing, the signature just gets appended to the original document. You cannot append a signature to most types of software for obvious reasons (some interpreted languages would allow this, but I don't know if it's done in practice).
The solutions to the signature problem vary based on the execution environment. For an executable binary, the signature is often stored in a separate file. In Java you can have a signature embedded in an executable JAR file.
Microsoft has a good reference for an introduction to the signing process.
It depends on what you are doing with it. If you want the certificate to be accepted by a browser in an SSL communication, then it must have a root certificate installed in the browser. The certificates generated by authorities already have their root certs installed in browsers.
If you are using the cert just to sign an assembly, then you don't need it. It depends on who is checking the cert and whether they care if the root is a known authority.
More here:
http://en.wikipedia.org/wiki/Root_certificate
To my knowledge, certificates have a "key usage" attribute that describes what uses the cert is intended for: SSL server, code signing, e-mail signing, etc. So I think it's up to the OS, or web browser, or e-mail client, to check these bits.
When a cert is called into action, the role it purports to perform is as important as identification. It's not just about identity, but also about role authorization. An email protection cert should not be able to perform server authentication. Security concerns dictate a necessary restriction in the power given through a single certificate. The underlying API should enforce the correct usage, be it through the OS or an abstraction such as the .NET Framework.
There are different certificate types because there are very different roles in authentication and authorization that would need them. Allowing different certificate types and hierarchies allow for a model of certificate chains, as found in the "Certification Path" on a certificate. A Server Authentication cert will need to have a top-level CA cert somewhere in the trusted root certificates... or be a part of a family tree of certs which ultimately does. 3rd party Certificate Authorities, I'm sure, price them on a scale of functionality and trust.
Boot To The Head is right... there is an Enhanced Key Usage attribute which provides a description of what the cert claims the role to be (e.g. Server Authentication; or in the case of my CA's cert: Digital Signature, Certificate Signing, Off-line CRL Signing, CRL Signing). Look at the details in a certificate's properties and you'll find it.
I'd also add that a .NET assembly has to be strongly named (which requires it to be signed) in order to be added to the GAC.
There are different types of certs... from the CA that is bundled in Win 2003 server, you can request:
Client authentication
Email protection
Server authentication
Code signing
Time stamp signing
IPSec
Other
What is the series of steps needed to securely verify a ssl certificate? My (very limited) understanding is that when you visit an https site, the server sends a certificate to the client (the browser) and the browser gets the certificate's issuer information from that certificate, then uses that to contact the issuerer, and somehow compares certificates for validity.
How exactly is this done?
What about the process makes it immune to man-in-the-middle attacks?
What prevents some random person from setting up their own verification service to use in man-in-the-middle attacks, so everything "looks" secure?
Here is a very simplified explanation:
Your web browser downloads the web server's certificate, which contains the public key of the web server. This certificate is signed with the private key of a trusted certificate authority.
Your web browser comes installed with the public keys of all of the major certificate authorities. It uses this public key to verify that the web server's certificate was indeed signed by the trusted certificate authority.
The certificate contains the domain name and/or ip address of the web server. Your web browser confirms with the certificate authority that the address listed in the certificate is the one to which it has an open connection.
Your web browser generates a shared symmetric key which will be used to encrypt the HTTP traffic on this connection; this is much more efficient than using public/private key encryption for everything. Your browser encrypts the symmetric key with the public key of the web server then sends it back, thus ensuring that only the web server can decrypt it, since only the web server has its private key.
Note that the certificate authority (CA) is essential to preventing man-in-the-middle attacks. However, even an unsigned certificate will prevent someone from passively listening in on your encrypted traffic, since they have no way to gain access to your shared symmetric key.
You said that
the browser gets the certificate's issuer information from that
certificate, then uses that to contact the issuerer, and somehow
compares certificates for validity.
The client doesn't have to check with the issuer because two things :
all browsers have a pre-installed list of all major CAs public keys
the certificate is signed, and that signature itself is enough proof that the certificate is valid because the client can make sure, on his own, and without contacting the issuer's server, that that certificate is authentic. That's the beauty of asymmetric encryption.
Notice that 2. can't be done without 1.
This is better explained in this big diagram I made some time ago
(skip to "what's a signature ?" at the bottom)
It's worth noting that in addition to purchasing a certificate (as mentioned above), you can also create your own for free; this is referred to as a "self-signed certificate". The difference between a self-signed certificate and one that's purchased is simple: the purchased one has been signed by a Certificate Authority that your browser already knows about. In other words, your browser can easily validate the authenticity of a purchased certificate.
Unfortunately this has led to a common misconception that self-signed certificates are inherently less secure than those sold by commercial CA's like GoDaddy and Verisign, and that you have to live with browser warnings/exceptions if you use them; this is incorrect.
If you securely distribute a self-signed certificate (or CA cert, as bobince suggested) and install it in the browsers that will use your site, it's just as secure as one that's purchased and is not vulnerable to man-in-the-middle attacks and cert forgery. Obviously this means that it's only feasible if only a few people need secure access to your site (e.g., internal apps, personal blogs, etc.).
I KNOW THE BELOW IS LONG, BUT IT IS DETAILED, YET SIMPLIFIED ENOUGH. READ CAREFULLY AND I GUARANTEE YOU'LL START FINDING THIS TOPIC IS NOT ALL THAT COMPLICATED.
First of all, anyone can create 2 keys. One to encrypt data, and another to decrypt data. The former can be a private key, and the latter a public key, AND VICERZA.
Second of all, in simplest terms, a Certificate Authority (CA) offers the service of creating a certificate for you. How? They use certain values (the CA's issuer name, your server's public key, company name, domain, etc.) and they use their SUPER DUPER ULTRA SECURE SECRET private key and encrypt this data. The result of this encrypted data is a SIGNATURE.
So now the CA gives you back a certificate. The certificate is basically a file containing the values previously mentioned (CA's issuer name, company name, domain, your server's public key, etc.), INCLUDING the signature (i.e. an encrypted version of the latter values).
Now, with all that being said, here is a REALLY IMPORTANT part to remember: your device/OS (Windows, Android, etc.) pretty much keeps a list of all major/trusted CA's and their PUBLIC KEYS (if you're thinking that these public keys are used to decrypt the signatures inside the certificates, YOU ARE CORRECT!).
Ok, if you read the above, this sequential example will be a breeze now:
Example-Company asks Example-CA to create for them a certificate.
Example-CA uses their super private key to sign this certificate and gives Example-Company the certificate.
Tomorrow, internet-user-Bob uses Chrome/Firefox/etc. to browse to https://example-company.com. Most, if not all, browsers nowadays will expect a certificate back from the server.
The browser gets the certificate from example-company.com. The certificate says it's been issued by Example-CA. It just so happens to be that Bob's OS already has Example-CA in its list of trusted CA's, so the browser gets Example-CA's public key. Remember: this is all happening in Bob's computer/mobile/etc., not over the wire.
So now the browser decrypts the signature in the certificate. FINALLY, the browser compares the decrypted values with the contents of the certificate itself. IF THE CONTENTS MATCH, THAT MEANS THE SIGNATURE IS VALID!
Why? Think about it, only this public key can decrypt the signature in such a way that the contents look like they did before the private key encrypted them.
How about man in the middle attacks?
This is one of the main reasons (if not the main reason) why the above standard was created.
Let's say hacker-Jane intercepts internet-user-Bob's request, and replies with her own certificate. However, hacker-Jane is still careful enough to state in the certificate that the issuer was Example-CA. Lastly, hacker-Jane remembers that she has to include a signature on the certificate. But what key does Jane use to sign (i.e. create an encrypted value of the certificate main contents) the certificate?????
So even if hacker-Jane signed the certificate with her own key, you see what's gonna happen next. The browser is gonna say: "ok, this certificate is issued by Example-CA, let's decrypt the signature with Example-CA's public key". After decryption, the browser notices that the certificate contents don't match at all. Hence, the browser gives a very clear warning to the user, and it says it doesn't trust the connection.
The client has a pre-seeded store of SSL certificate authorities' public keys. There must be a chain of trust from the certificate for the server up through intermediate authorities up to one of the so-called "root" certificates in order for the server to be trusted.
You can examine and/or alter the list of trusted authorities. Often you do this to add a certificate for a local authority that you know you trust - like the company you work for or the school you attend or what not.
The pre-seeded list can vary depending on which client you use. The big SSL certificate vendors insure that their root certs are in all the major browsers ($$$).
Monkey-in-the-middle attacks are "impossible" unless the attacker has the private key of a trusted root certificate. Since the corresponding certificates are widely deployed, the exposure of such a private key would have serious implications for the security of eCommerce generally. Because of that, those private keys are very, very closely guarded.
if you're more technically minded, this site is probably what you want: http://www.zytrax.com/tech/survival/ssl.html
warning: the rabbit hole goes deep :).