I need to verify a public certificate from Apple to authenticate a Game Center user server side (using generateIdentityVerificationSignatureWithCompletionHandler).
I have no problem getting the certificate from Apple (eg. https://sandbox.gc.apple.com/public-key/gc-sb.cer), but it is signed with an intermediate certificate (VeriSign Class 3 Code Signing 2010 CA) which in turn then is signed by a trusted root certificate (VeriSign Class 3 Public Primary Certification Authority - G5).
Obviously I need the intermediate certificate to authenticate the apple certificate- what would the normal approach be to obtaining intermediate certificates?
How should I go about getting it for this purpose?
Related
I have to create an SSL connection between a client and a server. I've created a keypair and signed my public key with my private key. The server won't trust this so I need to get it signed by a CA. I presume that the server will trust a certificate which has been signed by the same CA as was used to sign its own certificate. How do I do the business of creating the signed certificate with keytool? Sorry if this is duplicated information on the Oracle website, but for some reason their pages keep breaking my internet browser.
knowledge so far is based on answer here
I presume that the server will trust a certificate which has been signed by the same CA as was used to sign its own certificate.
Correcting your assumption here: A system trusts various major Certificate Authorities (CA) by default (eg: GeoTrust, Entrust, OpenTrust, Verisign, etc...). When you get your CSR signed by any of these known CA's, the server will trust by default, not just by the CA that signed the server's certificate.
What you could do to test your SSL connection between the client and the server is to work with self-signed certificates.
I've created a keypair and signed my public key with my private key
You shouldn't be doing this as a client. The server is supposed to do this. If the server is working with self-signed certificates, they need to provide the client with that certificate, so that the clients can trust them to make the SSL connection.
As a server, you could use the keytool to create a self-signed certificate. When you are generating a keypair using keytool, it will ask you few attributes like commonName, organizationName, etc... using these attributes, the keytool will create a self-signed certificate and associate it with the private key. All you have to do is export this certificate using the keytool -exportcert command. Once you have done this part, you would use this certificate to secure the server.
Once the server is secured, the server should give or the client this certificate, because it is self-signed and the client's system will not trust it until you explicitly trust it. If the server has secured using a certificate signed by a CA, it need not provide the client with any certificate, because, if it is a known CA, it will already be trusted by the client system.
We have a XMPP server using SSL certificates (for both the server and the clients).
We use a self-signed CA to sign those certificates. Now we want to stop using that self-signed CA, but we have no idea how to replace those certificates to ones signed by an authority like Digicert or GlobalSign, since we don't know what to buy to do the same we usually do (we usually just create a public key, then a request and we sign it using the self-signed CA, and then voila, we have a certificate ready for the client to use)
Any ideas?
Thanks a lot.
we usually just create a public key, then a request and we sign it using the self-signed CA, and then voila, we have a certificate ready for the client to use)
The process is the same as for a Certificate Authority, with the difference you probably have to pay for the certificate
generate a key pair,private and public. (Not only the public)
Generate a Certificate Signing Request including the public key, some data about the certificate as Common Name, and sign it with the private key.
Send the CSR to the Certificate Authority
The CA validates the CSR, builds the certificate and signs it with its private key
Finally the CA sends you the certificate
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.
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.
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.