Using a self-signed certificate is only recommended for development, not production.
What certificate should a team buy when Application moves to Production - TIA
Ideally, certificates are bought from the certificate authority for production scenarios.
a certificate authority or certification authority (CA) is
an entity that issues digital
certificates. A digital certificate certifies the
ownership of a public key by the named subject of the certificate.
This allows others (relying parties) to rely upon signatures or on
assertions made about the private key that corresponds to the
certified public key. A CA acts as a trusted third party—trusted both
by the subject (owner) of the certificate and by the party relying
upon the certificate. The format of these certificates is specified by
the X.509 or
EMV standard.
Reference: https://thecodeblogger.com/2020/06/20/service-principal-and-certificate-with-azure-key-vault/
Related
I can't find good information regarding certificate pinning in iOS and Amazon Certificate Manager.
They recommend you don't pin against an ACM certificate.
https://docs.aws.amazon.com/acm/latest/userguide/acm-bestpractices.html#best-practices-pinning
We recommend that your application not pin an ACM Certificate
The reason they don't recommend it is that:
To renew a certificate, ACM generates a new public-private key pair.
Instead, they recommend:
If you're using a public certificate, pin your application to all available Amazon root certificates.
I understand why not to pin to an ACM Certificate - because you will have to release updates with new certificates risking possible bricking of clients. You also can't pin against the public key because it will change.
What I don't understand is how pinning against only the root certificates is ok? Will it still prevent man in the middle attacks? How is this more secure?
Can someone explain it better?
It would not be more secured to pin against the root certificate. I think what the Amazon documentation trying to recommend is a way that would not break your network connection in the case that when the certificate expires and renews.
Here's the quote from this website explaining the different kinds of certificate pinning:
https://carvesystems.com/news/cert_pin/
Leaf Cert: A leaf cert is the top level cert in a certificate chain.
Pinning a leaf certs brings us to almost complete certainty that the
certificate matches. However, if you cycle your leaf certs often,
updates need to roll out fairly frequently to make sure your
customer’s app continues to work.
Intermediate Cert: The intermediate cert lives between the leaf and
root cert. In this case, pinning against the intermediate cert, you’re
putting your trust in the intermediate certificate authority.
Therefore, you can update your server’s leaf cert more often, as the
validation of certs occurs on the intermediate cert.
Root Cert: Finally, the root cert comes from the trusted certificate
authority. Pinning the root cert alone puts trust in the root cert
authority, as well as all intermediaries that the root cert authority
trusts.
Hope this helps
I am looking at a clear answer on to how to renew the CA successfully in EJBCA. We have thousands of client certificates already issued by the EJBCA which is actually working as a subCA signed by an external CA. The process is indeed documented here https://www.ejbca.org/docs/Renewing_a_SubCA_Signed_by_an_External_CA.html but it does not state clearly, what will happen to the already issued client certificates. Will they continue to be successfully validated via the new CA?
That link give two options for renewing the key:
1. Using the same CA signing key
If you refer to RFC 3647, this is the correct definition of a renewal. In this case, the keys remain the same and the certificate Subject remains the same. Effectively, the new certificate is the same as the old albeit with different dates.
Relying parties will trust this certificate in the same way as they trusted the original.
2. Generating new CA signing keys
The correct term for this is a re-key. The key changes and the Subject stays the same. The certificate is a different certificate as far as any relying parties are concerned. This may mean more work for you.
You'll first need to ascertain what will happen to the original CA certificate. Will it expire or be revoked, or will it still be valid?
If it's being retired, you'll need to replace all certificates issued by that original CA certificate as they will only verify through the original CA.
If not, and you're re-keying for other reasons, for example the original CA certificate's CRL has become too large to manage, then there is no need to rush into replacing all your subscriber certificates. The old CA certificate will still verify those certificates, while subscriber certificates issued by the new CA certificate will be verified by the new CA certificate.
I have a pretty basic understanding of PKI/SSL/TLS but not a lot of experience with it. I have several iOS devices connecting through a VPN to an internal server. The server is reachable, but we receive an SSL error. I understand I need to add the CA's cert to the iOS devices - but I'm confused as to if I add the CA's public or private cert?
According to this blog It's private, but I want to verify first.
http://nat.guyton.net/2012/01/20/adding-trusted-root-certificate-authorities-to-ios-ipad-iphone/
Any advice or further documentation would be greatly appreciated.
There's no such thing as a private certificate.
In an asymmetric encryption you have two keys - the public key and the private key. As the names suggest, the private key is kept private and the public key is distributed. A certificate is a separate object that serves to tie a public key to a "security principal" - i.e. a person, server, certification authority or whatever.
So your VPN server has a certificate. This certificate states that the given public key X belongs to your server. When you contact the server, it gives you its certificate and public key, then can prove it has the corresponding private key by you giving it a randomly generated number to sign/decrypt.
However, how do you know the server isn't lying when it gives you the certficate? Because the certificate is signed by a third party - a certificate authority. The CA's signed the server's certificate with its private key to confirm that what it says is true. You can verify this signature with the CA's public key. But how do you know that the CA's public key actually belongs to the CA?
As you can see, this can go on for a while, creating a chain of certificates or chain of trust. Eventually you have to have some certificates that you just trust without any third parties - the root certificates. iOS comes with a set of these that Apple trusts, but does not include the root of the chain for your VPN server. That is the certificate that you are being asked to install.
Openstack Keystone PKI uses two certificates as this document mentions:
https://www.mirantis.com/blog/understanding-openstack-authentication-keystone-pki/
CA certificate and the signing certificate.
My understanding so far: Signing key is used to sign the user token while the signing certificate contains the corresponding public key and will be shared with the service endpoint to be used while decrypting the user token.
Is this correct? If so, what is the purpose of the CA certificate and the CA key?
I'd suggest the OpenStack documentation at http://docs.openstack.org/admin-guide-cloud/content/certificates-for-pki.html
PKI stands for Public Key Infrastructure. Tokens are documents, cryptographically signed using the X509 standard. In order to work correctly token generation requires a public/private key pair. The public key must be signed in an X509 certificate, and the certificate used to sign it must be available as a Certificate Authority (CA) certificate.
Tokens are both signed and verified. There's no decryption.
The certificate and certificate authority used can be internal or external and how the cloud provider choses to configure it is up to them.
In PKI environment certificate(signing cert) is signed by CA. CA is usually external entity but if you use keystone-manage pki_setup to generate the signing keys it first setup the CA locally and sign the certificate which keystone uses.
CA key is used for CA, keystone do not have any use of it.
Keystone just need own private key, Signed Certificate and CA certificate.
Hope this is useful.
-Thanks
You hear a lot about how you can use SSL pinning to increase the security in your app. I was always under the assumption that SSL pinning is only helpful if you use a self-signed cert. Are there benefits of SSL pinning when using a cert signed by a cert authority, or does the CA make that unnecessary?
SSL/TLS has some issues, and the root of those issues is the CA system. By default, your browser trusts a bunch of CAs. Other than a few basic checks such as hostname, etc, the real power of the SSL comes from the verification of the certificate via the intermediaries until you get to a certificate that you trust.
Certificate pinning specifies that you will only trust a given certificate for a given web site. That is to say, if you received a "valid" certificate signed by a different CA (even if you trusted that CA) you would not trust it for this site.
In short, the fact that the CA has signed a cert does not reduce the need for certificate pinning.
For example: Companies sometimes intercept SSL. To do this, they actually serve the client a different SSL certificate that is valid for the host that the client is trying to access. Because they can insert any certificate into the trusted root (windows via GPO) they can insert their certificate instead of the actual one issued by the host. In this scenario, the SSL interception is transparent to the user. They are still being issued a "valid" certificate that is signed by a CA they trust (whether they know it or not). If you had been using certificate pinning, the new cert would be rejected.
There are cons to certificate pinning, mostly around the management of the cert as it expires etc.
See this link for more info.