There are already answers about generating self signed certificate with openssl like this. However, what I want is a certificate that can do nothing but authenticate and encrypt the traffic to predefined websites.
A certificate generated by the following command
openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days 365
has basic constraint / certificate authority set to YES, meaning that it can be used to sign other certificates. Suppose that my domain is mystackoverflow.com, an attacker who steals my private key would not only be able to MITM the connection to mystackoverflow.com, but also facebook.com or google.com because he can sign forged certificates with the said private key and get trusted by my system.
So the question is, how do I minimize the power of this certificate so that it cannot sign additional keys, sign codes, encrypt emails or do anything other than protect https connection to a specific website?
I want is a certificate that can do nothing but authenticate and encrypt the traffic to predefined websites...
So the question is, how do I minimize the power of this certificate so that it cannot sign additional keys, sign codes, encrypt emails or do anything other than protect https connection to a specific website?
There are three parts to this question.
First is how to "authenticate and encrypt [stuff]". That's handled by Key Usage and Extended Key Usage. In particular, bits like digitalSignature (signing key exchange, like Diffie-Hellman), keyEncipherment (key transport, like RSA), serverAuth, etc.
Second is how not to mint certificates. For end entity certificates (i.e., server certificates), you remove the CA=true basic constraint and you remove the keyCertSign bits. You will still need a intermediate CA with the ability to sign end entity certificates because that's where the policy of "this CA can only issue for these names" is applied.
Third is how to apply a policy like "this CA can only issue for these names". Under the IETF's rules for PKIX in RFC 5280, you can do it in the CA certificate with the Name Constraints extension. See section 4.2.1.10 for details.
Under CA/Browser Forum rules, you can do it because they have policy objects. But I don't know how to do it under the CA/B (it may be the same as the IETF).
You have to be careful with the IETF gear. They have extensions, but they don't have policies. So you need to ensure you are working within and existing extension, and not forging new policy. See OID for certificates issued under IETF policy? on the PKIX mailing list for more details.
The CA/B Forum is significant because browsers follow the CA/B Forum rules, and not the IETF. And the CA/B Forum and IETF have different requirements in a few key areas. That's why a certificate created with OpenSSL (which follows IETF guidelines) fails to validate in Browsers (which follow CA/B Forum guidelines).
A certificate generated by the following command: openssl req ...
It used to be how to do it, but its not how to do it today. Today it produces a malformed certificate (which may or may not cause problems, depending on your user agent). For the question you cited, one answer in particular tells you why its incorrect and how to do it.
.. an attacker who steals my private key ..
So the question is, how do I minimize the power of this certificate so that it cannot sign additional keys, sign codes, encrypt emails or do anything other than protect https connection to a specific website?
If you fear that the attacker might steal the key to the certificate and then sign other things with it, then you should not create a self-signed certificate. Instead create first your own CA. Then create a leaf-certificate which can not be used to sign certificates and sign it by your own CA. Once this is done put the private key of the CA far far away (offline or even destroy it if you don't need it to sign more certificates).
With this setup an attacker could still steal the identity of the certificate if it gets its private key. But since this certificate is not a CA itself (unlike normal self-signed certificates) it can not be used to sign new certificates.
Related
I have some secrets that I would like to keep in Azure Key Vault. I know I can use a client id and certificate to authenticate with Key Vault instead of using a client and and secret following these steps:
Get or Create a Certificate
Associate the Certificate with an Azure AD application
Add code to your application to use the Certificate
Most examples use either makecert or New-SelfSignedCertificate to create the certificate. Is a self signed certificate problematic in this case for a production application? This is only for an application to authenticate with Azure Key Vault and it's not something a client will ever see in their browser.
If a self signed cert is still frowned upon in this case then is purchasing a cert from a trusted authority the same process as purchasing an SSL/TLS certificate? Is it even the same type of certificate?
There is (with some caveats) nothing inherently wrong with using a self-signed certificate. There is no difference from a pure crypto perspective between a purchased and a self-signed certificate. The sole difference is that a purchased certificate has been signed by one or more certificate authorities (CAs) who distribute their public keys with most browsers/operating systems/etc. This means that a user can have a much higher confidence that a purchased certificate is legitimate, while they must take a leap of faith to accept a self-signed certificate.
In your case, however, you seem to be able to control the client application, and actual users should never see this certificate. Therefore, you can use a self-signed certificate without worry, so long as you take precautions to prevent man-in-the-middle attacks (i.e. someone generating their own self-signed certificate and pretending to be you.). One of the most effective ways to do this is via certificate pinning. In essence, you ship the public key for your certificate with you client application, and your client application will only accept certificates that provide that public key. This makes it much more difficult for a malicious actor (who has not stolen your certificate) to preform a man-in-the-middle attack.
TL;DR: So long as you take steps to prevent man-in-the-middle attacks, and you keep your certificate secure, there is nothing wrong with using a self-signed and self-generated certificate to secure non-user-facing connections.
Newbie question: some vendors propose solution like generating dynamic certificates to allow user who haven't classic certificate to sign documents. But why not just generate private/public keys alone instead of bothering with certificate format ?
The purpose of the (public key) certificate is to bind the public key to the identity of its subject (i.e. the owner/entity associated with the key pair), and possibly various attributes telling you what the certificate may be used for. (You may be interested in this question on Security.SE.)
You always sign with the private key (not the public key or the certificate), but the public key or certificate are often attached with the signed document.
If you have an explicit list of public keys you know and can link independently to a user, you don't need a certificate.
The certificate allows third parties (who have signed the certificate) to assert the binding between the identifier and the public key. Even if you don't know that identity in advance, you can link the signature to the signer's identity as long as you trust the entity that signed the certificate.
Dynamically generated certificates may not be very useful in this case, unless you trust the party that generates the certificate dynamically (I'm not sure if you meant the tool itself or perhaps a website that you would also know).
Often, X.509 certificates will be used just to attach to that signature, because the tooling requires it, whereas you may be able to match the public key against an identity you know directly in the tool with which you verify the signature. Sometimes, it's also just done in anticipation of a case where it will be useful one day.
For example, if you publish your own artifacts to the central Maven repository, you will be required to sign it with your PGP certificate (often only referred to as the PGP public key). Yet, no verification of the certificate is made at all during the process (PGP certificate with only its self-signed signature is good enough). This makes this process relatively pointless in this case, but makes it possible to be stricter in which artifacts you want to use, if you're able to verify those certificates later on.
It's the same but you need a third party to consent that private key belongs to whom ever you think it belongs to.
Signing proves first of all authorship (or approval) of the document by some person. And the key alone won't prove anything. This is what the certificate is needed for - some certificate authority signs the certificate of the user and certifies that the keypair belongs to the person (or legal entity) to which the certificate is issued. The reader of the document can ensure that the signature is valid not by just computing the signature itself, but also by validating the certificate and seeing the name of the certificate owner.
I don't quite understand what vendors can issue certificates dynamically - issuing certificate in such way that they are not self-signed (and self-signed certificates make little sense in context of document signing) requires that the private key, used for signing the certificate, should be embedded into software of those vendors, and as such it's also prone to misuse.
I've read about SSL protocol and now, I know how it encrypts data. But there is something I couldn't understand. With SSL , you're sure you're sending data to and getting data from correct server. But how?
I mean if I create a fake certificate and send it for requests of special website, how do browsers ( or other programs) detect the fake certificate?
Edit: I didn't mean to create a self-signed certificate. I meant how can someone validate my certificate if I create a certificate that its issuer and subject ,etc are something to real certificate! (the only things that are not real is Public key & signature)
TL;DR summary:
Validity of a server certificate is established by:
Host name verification
Verifying the signatures of the entire certificate chain
Performing additional checks on meta data for each certificate
Checking the revocation status of each of the certificates involved
Checking whether the self-signed root certificate of the chain is among the certificates that one trusts by default
Explanation
Let's assume you want to connect to https://mail.google.com (you can try this out in your browser!).
The (real) server will respond with a certificate that is issued to mail.google.com, i.e. in the 'Subject' field of the certificate you will find the Common Name (CN) 'mail.google.com' - cf. RFC 5280 for details on the fields of certificates. The fact that the subject is linked to the site URL is very important for the security of the whole model, and it is actively checked by your TLS implementation ("host name verification"), because otherwise there would be room for Man-In-The-Middle attacks. I.e. somebody could acquire an otherwise valid certificate and impersonate mail.google.com without you taking any notice of it.
In addition to the host name verification, your TLS implementation will also check the "validity" of the certificate. The whole procedure is rather complex and does include checking the trustworthiness of the certificate, but additionally a lot of other things will be checked, more on that in a minute.
If you view Google Mail's certificate in your browser, you will notice that there are actually three certificates shown:
mail.google.com
Thawte SGC CA
Class 3 Public Primary Certification Authority (VeriSign)
The model is that there are a few (well, unfortunately not so few anymore) trusted root certificate authorities ("root CAs") that either you could choose on your own or (more likely) that come preconfigued with your software (e.g. browser) that are blindly trusted. These trusted authorities form the anchors of the entire trust model of "PKI" (Public Key Infrastructure). The basic idea is that the trusted entities may issue certificates to other authorities and grant them permission to again issue certificates (these authorities are called intermediate certificate authorities). The intermediate CAs may again recursively apply this procedure up to a certain point, the number of intermediate CAs between an actual end entity certificate and a root CA certificate is generally limited.
At one point, an intermediate CA will issue certificates to an "end entity" ("mail.google.com" in our example). Now the process of issuing a certificate actually means that the party requesting a certificate will create a public/private key pair first, and use them to authenticate a certificate request that is sent to the certificate authority. The issuing authority creates a certificate for the subordinate entity (either intermediate CA or end entity) by "signing" that certificate using its own private key using an asymmetric algorithm such as RSA and by additionally including the public key of the requesting party within the newly generated certificate. The root CA possesses a so called self-signed certificate, i.e. the root CA is the only authority that may sign their own certificate and include their own public key. The private key remains hidden at all times, of course.
The recursive nature of the certificate issuing process implies that for each end entity certificate there is a unique way of establishing a "chain" of certificates that leads up to a root certificate authority. Now when you are presented with an end entity certificate while trying to connect to a TLS-secured site, the following procedure will be applied recursively until you end up with a root CA certificate:
Find the certificate of the authority that issued the certificate to be validated (see RFC 5280 for details). If none is found: exit with error.
Take the public key of the issuing certificate and verify the signature of the to-be-validated certificate using this public key.
Check a lot of additional things such as whether the certificate has neither expired nor is it not valid yet, "policy constraints", "key usages", "extended key usages"... (again, the gory details are in the RFC).
Certificate revocation status (more on that later)
If all checks were positive, you will ultimately end up with a certificate being self-signed, i.e. where the subject is also the issuer (such as the VeriSign certificate in our example). Now the last thing you have to verify is whether this certificate is among those that you blindly trust: if it is, all is well and the connection will succeed, if it is not, the connection attempt will be rejected.
As if this were not complicated enough already, the checks described so far do not handle cases where once valid certificates suddenly become rogue, examples being cases where a certificate is stolen or private keys are compromised (think of Comodo and DigiNotar). In these cases, the normal procedure is to "revoke" those certificates gone bad, that is you want to mark them as being invalid starting from a distinct point in time (they will expire at some point anyway, but for the remainder of that period they shall already be marked as invalid). For these cases, CAs have the possibility to issue CRLs (a catalog of certificates declared as invalid) or OCSP responses (information for one or in rare cases a set of certificates) that provides clients with information whether a given certificate has been marked as invalid or not. The revocation status needs to be checked for all certificates in a chain, should one of them be marked as invalid then the end entity certificate cannot be trusted and the connection must be rejected as well.
SSL certificates are signed by a certificate authority (CA), which is someone the user already trusts (or more likely, the people who designed their operating system trusts).
The CA digitally signs the certificate using public key encryption. The basic explanation is that the CA has a "private key", and a "public key" that everyone knows. Via some math I don't understand, the CA can create a signature using its private key which can easily be verified with its public key (but the public key can't be used to create a new signature).
When you get an SSL certificate from a server, you get the server's public key, and a signature from a CA saying that it's valid (along with some other info). If you know and trust that CA, you can check the signature and determine if it's valid. You can also use a certificate revocation list to make sure it wasn't revoked.
So basically, you can recognize a bad SSL certificate because it isn't signed by a certificate authority that you trust.
Any fake certificate you create will be a self-signed certificate.
The browser will display big scary warnings when connecting to a site with a self-signed certificate which the user will promptly ignore.
In order to avoid warnings, you need a certificate signed by a certificate authority that the browser trusts, such as VeriSign.
These companies will hopefully make sure that you actually own the domain for the certificate they're signing.
Re: Edit: You can only create a non-self-signed certificate if you get it signed from a trusted CA.
They will refuse to sign a certificate for a different subject.
Process from my understanding:
server sends servers public key
server sends certificate (all information encrypted by trusted CA with their private key)
Your PC decrypts certificate with public key (built into OS from trusted CA)
Your PC hashes (with sha1 and sha256) the servers public key
Your PC compares the hashes of servers public key with certificate stored hash, if not same browser will block site
Your PC compares allowed domains from certificate and the domain, if not allowed, if not same browser will block site
Your PC compares valid date from certificate and your date, if not valid browser will block site.
To fake this you would either need to:
obtain a CA private key (extremely hard to get),
be a CA,
be part of the 5 eyes (Government intelligence agency alliance) and ask a CA for their private key
So if you see a padlock in the address bar you are almost always safe.
Certificates work because they follow a chain of trust. Certificates have a chain of one or more issuers that are trusted; this chain is the backbone of why it works at all. Browsers and nearly all SSL certificate libraries do this chain check, or at least provide the option to.
Self-signed certificates (or those issued by chains that end in a self-signed certificate) would fail this check.
I have a question regarding validation of digital signatures using a self-signed certificate:
The following tutorial works for me:
http://www.oracle.com/technetwork/articles/javase/dig-signature-api-140772.html
However, when a X.509 certificate is self-signed, how can a receiver trust certificate data attached to an XML message? Any one can generate a self-signed cert and claim to be the same sender. The validation in the above tutorial always returns true. Sender’s cert must be loaded to receiver’s truststore, so receiver can use whatever in the truststore to validate signed doc. I cannot find any reference for such a scenario.
Your understanding is correct - with self-signed certificates anyone can create a certificate and signature validation will be ok. The reason is that signature validation performs first of all cryptographic operation, which is completed successfully. The second step is to validate the certificate itself AND also it's origins. When the CA-signed certificate is used, the certificate is validated using CA certificate(s) up to trusted CA (or known root CA). With self-signed certificate validation is not possible. In the above tutorial the procedure of certificate validation was skipped for simplicity as it's quite complex and beyond the scope of tutorial.
The problem you're describing is usually addressed by Public Key Infrastructures (PKI).
This is the traditional model for verifying certificates for HTTPS sites, for example. It starts with a set of trusted Certification Authorities (CAs) from which you import the CA certificates as "trusted". The entity certificates that you get are then verified against this set of trusted anchors by building a certification path between the certificate to verify and a CA certificate you know (linking the certificate to a trusted issuer, perhaps via intermediate CA certificates).
The various rules to do this are described in RFC 5280. The PKI system doesn't apply only to web servers, but to any entity (there are additional rules for web servers to verify that they're the one you want to talk to, on top of having a valid certificate).
(In particular because the choice of which CA certificates to trust is often done on behalf of the user, at least by default, by the OS or browser vendor, this model isn't perfect, but it's the most common in use.)
Alternatively, there's nothing wrong with establishing a list of self-signed certificates you would trust in advance.
Either way, you need to pre-set what you trust by mechanisms out of bands (e.g. by meeting someone you trust and using the certificate they give you in person).
This PKI model goes hand-in-hand with the X.509 format thanks to the notion of Issuer DN and Subject DN. You could have other models, for example relying on PGP certificates, where you would build a web of trust; you would still need an initial set of trusted anchors.
For XML-DSig in Java, you should implement a X509KeySelector that only returns a key that you trust. In a simple scenario, where you have a pre-defined set of self-signed certificates you trust, you can iterate over a keystore containing those trusted certificates. Otherwise, use the Java PKI Programmer Guide (as linked from the tutorial you've used).
My question is about certificates specifically in ssl but I think the questions should apply to all certificates. I have included the SSL procedure for the sake of clarity.
In SSL this is what I understand the procedure is:
1)Client
sends supported crypto algorithms
sends client nonce
Server
chooses (and sends) a
symmetric algorithm
a public key algorithm
a MAC algorithm
sends it's certificate
sends server nonce
Client
verifies certificate
Extracts public key
Generates a pre-master secret key (pms)
encrypts with servers public key and sends
Client and Server
compute master secrete (MS) from PMS and nonces
PMS sliced to generate two encryption & two mac keys
Client
sends a mac of all handshakes (to ensure they were not previously modifide)
Server
sends a mac of all handshakes
Question
What stops a man in the middle attack from happening at step two? Why can't a man in the middle, say trudy, capture the certificate sent by the server and change the public key in it (to something it has the private key to).
I assume that the certificate is encrypted somehow.
However the server cannot encrypt the certificate because the client does not have the public key yet. When the server gets the key from an authority (like veri-sign) would the key be pre-encrypted using verisign's public key? I think this should work because all web browsers should have the public keys of most authorities.
No, the certificate is not encrypted. But it is signed by a certification authority (CA). Since those check the information included in the certificate (especially the URL to which the cert belongs), there shouldn't be a second valid certificate for a given URL.
The cert of the CA is checked against a trust store (e.g. in your browser). If this truststore is compromised, or if you trust not valid certificates, there is no protection against man in the middle attacks
Certificates are signed by some trusted authority, such as Verisign.
The certificates for these root authorities are built right into the browsers when you download them. You can view the root certificates in Firefox, for example, by going to tools-->options-->advanced-->encryption-->view certificates-->authorities.
If any one of these root-certificate authorities is compromised, however, you are right that a certificate could be forged, making a man-in-the-middle attack possible.
You actually pointed out a weak spot of PKI.
Say Trudy is in the middle of you and yourbank (bank.com). Trudy can change the public key at will at step 2 but the certificate's signature will be invalid. So Trudy has to find a way to generate the signature again. It's safe to say that the trusted CAs will not do this for him. So he has to sign with a fake CA, which is not trusted by your browser. This is still safe theoretically.
However, most browsers (especially IE 6) display a vague security warning and most people don't understand and just ignore, according to some tests.