We have an Azure web role deployed that uses HTTPS. We upload a certificate to azure and shortly after the portal refreshes and two more certificate appear. This is not a wild cart certificate and maybe this is standard behavior, but I haven't seen it before.
The original certificate is named something like:
subdomain.domain.com
The three certificates that appear are named like so:
VeriSign Class 3 Public Primary Certification Authority - G5
Class 3 Public Primary Certification Authority
VeriSign Class 3 International Server CA - G3
Are the 3 certificates I mentioned normally generated or is this an issue I should be looking into?
We have a similar deployment that has an ssl, but does not generate these extra certificates. This is what triggered our concern and has me asking why ...?
When you enabled HTTPS endpoint in any web application and bind SSL certificate to it, the certificate bind to HTTPS endpoint is could be a single certificate or it could be a chain and
it is depend on several factors as below:
When the certificate is created as self signed ROOT then it will have only one certificate in the chain. This certificate can not be validated to have SSL tunnel because there is no other part to verify it and that why it is called self signed root
When you buy certificate from a reputed CA (Certificate Authority) in almost all cases you will get 3 (or more) certificates:
2.1. Root Certificate : This certificate is helps to create a SSL tunnel between two machines using PKI security Infrastructure.
2.2. Intermediate Certificate -> This is to create a chain with multiple certs as if needed
2.3. Domain Certificate -> This is for your *.domainname.com or domainname.com
Here is an example of chained SSL certificate at https://mail.google.com
And all of these certificate are chained into one single PFX (if private key embedded into certs) or CER (without any Private Key) so when you deploy only ONE PFX cert, you see the chain is open and all certificates are listed.
If you browser your url and open the certificate view through browser, you will see exactly same chain as you could see in your portal and you can also verify the certificate thumbprint as well to match.
Related
According to TLS connection definition, for example, as the client-side, I use keystore to store my private key and certificate, and use truststore to store some kinds of certs. On the server-side, that call it Youtube, it has a root certificate called Youtube.pem which is signed by Google.crt CA.
I know the truststore is to verify the 3rd party certificate during handshake
My question is what should my truststore actually store during handshake?
Youtube.pem (the CA signed certificate sent from 3rd part)
Google.crt (the CA certificate)
According to TLS connection definition, for example, as the client-side, I use keystore to store my private key and certificate, and use truststore to store some kinds of certs.
Yes, but you only need a keystore if you want to use client side authentication. Note that "keystore" and "truststore" indicate how the store is used, they can be of the same type (e.g. PKCS#12) and even the same file.
On the server-side, that call it Youtube, it has a root certificate called Youtube.pem which is signed by Google.crt CA.
No, YouTube is a service, it has a leaf or end-entity certificate. The root certificate is that of a third party CA. The end-entity certificate is usually signed by an intermediate CA certificate, and that is in turn signed by a self signed root certificate.
I know the truststore is to verify the 3rd party certificate during handshake
It is used to validate and verify the trust path from leaf certificate to a trust anchor in your truststore. The trust anchor is usually one of the root certificates stored in your truststore. The leaf certificate is indicated by the end entity / server, the intermediate certificates are usually sent by the server as well, but they could also be retrieved from a cache.
In the case of YouTube, the Google root CA is used, possibly using the GlobalSign root through a linked certificate if the Google root is not present in the trust store.
So your truststore should either contain the Google root certificate or the GlobalSign root for the connection to work in this example.
I have the company CA signed certificate, intermediate and server certificate in the identity store ( .jks) but still the browser says , cannot be verified by a trusted authority error. Using weblogic -10.3.1 from the weblogic logs i also notice this -
Invalid/unknown SSL header was received from peer x.y.z.12 during SSL handshake
But when I install the root and intermediate certificates into certmgr.msc then when i access the url again in a new window it has no error on the browser and also no error log in the weblogic server.
What could be wrong ?
Global CA's have their root and intermediates recognised by all the modern browsers. However when browser encounter s a certificate whose intermediate and roots aka chain certificates & ca certificates are not a part of its trust store so it fails to chain the leaf certificate to its issuer. So in order to mitigate thi, the roots and intermediates of the company ca must be added so that the browser can verify the complete chain.
Agreed .but thats how the trust works. The company issues ca certificate is known only to your organization but browsers are accessed globally and if you want make the certificate trusted in all the browsers then either you switch to public ca issued certificates or get your root certificate cross signed by a global ca root.
Does a non-self-signed certificate, imported into root store, require a (self-signed) issuer to also be imported into the root store?
Suppose I've a certificate A that is signed by another certificate B. Is it then sufficient to only import A into the root store, i.e. certificate validation stops at A, or should B also be imported into the root store for proper certificate validation?
The reason I'm asking this question, is that I've encountered different results with different products (e.g. web browser or system), and so I want to know the right way.
You should include Cert B in truststore. As mentioned in the comments, your mileage may vary as clients, as well as servers, implement RFC differently.
In terms of rules, spec for x.509 certs is in IETF RFC 5280. The key information is that for SSL handshake to happen client should do a full cert chain validation, which ends up with a self-signed certificate that is in your trust store.
Your Cert is not self-signed, it is issued by a different CA (cert B). If you do not have B in your truststore, then trust chain is broken. However, again as mentioned above, it is possible that client will not validate the full cert chain.
Think of it this way. Your client is presented with Cert A, which is signed by "B". Client should verify that signature on A is fine, which means it needs (certificate of) "B". If B is a "root" CA or self-signed, its "issuer" and "subject" fields will match. And if that Cert B is in your TrustStore, you are golden.
It's the job of the server to send you a certificate list for TLS.
This is a sequence (chain) of certificates. The sender's
certificate MUST come first in the list. Each following
certificate MUST directly certify the one preceding it.
There is a visual representation of certificate chain verification here. Hope it helps.
I am currently developping a Windows 8 metro app. This app will not be available in the Martketplace but will be distributed by sideloading.
For this it is necessary to sign the app with a certificate and import the same certificate on the client machine.
I never made such a certificate? How should I proceed?
I also read the publisher name of the app should be the same as the publisher name in the certificate...
Who knows how to make such a certificate? A commercial certificate from for example Verisign is currently not an option.
If a commercial (payed for) certificate is not an option there are three other ways to get a certificate:
1) If your company has an own root certificate (trusted by a public Certificate Authority like VeriSign) you (or an admin) can derive a software signing certificate from that.
2) Your company could setup an own certificate server to issue own certificates. If the certificates are only used inside the company and the root certificate is trusted (imported in the certificate store for trusted root authorities) on all machines you could use a software signing certificate derived from the root certificate. See http://www.esecurityplanet.com/network-security/how-to-run-your-own-certificate-authority.html.
3) You could use a self signed test certificate that is not derived from a root certificate. Use makecert to create one (see How do I create a self-signed certificate for code signing on Windows?). When installing the App the user will be asked if he trusts this certificate that has no known publisher.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 2 years ago.
Improve this question
I'm not clear on the difference between a CA key and a certificate. Isn't a CA key simply a certificate? Let me try and clarify with an example.
I have a client and a server. I'm only trying to validate my connection to my server and not trying to establish trust to others so I don't care about signing with a real CA.
Option 1: Generate a self-signed CA (ssCA) and use that to sign a certificate (C). I then install ssCA into the root keystore on my client and setup my server to use certificate C.
Option 2: Generate a self-signed certificate (SSC). Install SSC into the root keystore on my client. Setup my server to use certificate SSC.
The second option seems like a much simpler process. Should that still work?
First, about the distinction between key and certificate (regarding "CA key"), there are 3 pieces used when talking about public-key certificates (typically X.509): the public key, the private key and the certificate.
The public key and the private key form a pair. You can sign and decrypt with the private key, you can verify (a signature) and encrypt with the public key. The public key is intended to be distributed, whereas the private key is meant to be kept private.
A public-key certificate is the combination between a public key and various pieces of information (mostly regarding the identity of the owner of the key pair, whoever controls the private key), this combination being signed using the private key of the issuer of the certificate.
An X.509 certificate has a subject distinguished name and an issuer distinguished name. The issuer name is the subject name of the certificate of the entity issuing the certificate. Self-signed certificates are a special case where the issuer and the subject are the same.
By signing the content of a certificate (i.e. issuing the certificate), the issuer asserts its content, in particular, the binding between the key, the identity (the subject) and the various attributes (which may indicate intent or scope of usage for the certificate).
On top of this, the PKIX specification defines an extension (part of a given certificate) which indicates whether a certificate may be used as a CA certificate, that is, whether it can be used as an issuer for another certificate.
From this, you build a chain of certificates between the end-entity certificate (which is the one you want to verify, for a user or a server) and a CA certificate you trust. There may be intermediate CA certificates (issued by other CA certificates) between the end-entity certificate of your service and the CA certificate you trust. You don't strictly need a root CA at the top (a self-signed CA certificate), but it's often the case (you may choose to trust an intermediate CA certificate directly if you wish).
For your use case, if you generate a self-signed certificate for a specific service, whether it has the CA flag (basic constraints extension) doesn't really matter. You would need it to be a CA certificate to be able to issue other certificates (if you want to build your own PKI). If the certificate you generate for this service is a CA certificate, it shouldn't do any harm. What matters more is the way you can configure your client to trust that certificate for this particular server (browsers should let you make an explicit exception quite easily for example). If the configuration mechanism follows a PKI model (without using specific exceptions), since there won't be a need to build a chain (with just one certificate), you should be able to import the certificate directly as part of the trust anchors of your client, whether it's a CA certificate or not (but this may depend on the configuration mechanism of the client).
Both options are valid, option 2 is simpler.
Option 1 (setting up your own CA) is preferable when you need multiple certificates. In a company you might set up your own CA and install that CA's certificate in the root keystore of all clients. Those clients will then accept all certificates signed by your CA.
Option 2 (self-signing a certificate without a CA) is easier. If you just need a single certificate, then this is sufficient. Install it in the keystores of your clients and you are done. But when you need a second certificate, you need to install that again on all clients.
Here is a link with further information: Creating Certificate Authorities and self-signed SSL certificates
You can openssl x509 -noout -text -in $YOUR_CERT to see the differences between files contents:
In your self-signed CA, you can seeļ¼
X509v3 extensions:
X509v3 Basic Constraints:
CA:TRUE, pathlen:0
And in your self-signed certificate, it's:
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
If you need more certificates (C), you need to create a self-signed CA (ssCA).
If you need a single certificate, you can just create a self-signed certificate (SSC).
To trust the single certificate (SSC), you need to install SSC into the root keystore on your client.
To trust many certificates at once, you need to create a self-signed CA (ssCA), then install ssCA into the root keystore on your client.
You must always have a root CA, the CA has a key that can be used to sign a lower level certificate and a root certificate that can be embedded in the accepted root certificates on the client and is used to verify the lower certificates to check they are valid. Self signed just means you are your own CA. Whenever creating a self signed certificate you create a ca, then sign a site cert with that CA.