(This is for a new project, so I'm still considering options.)
I've got a server and client (phone app) communicating via gRPC, and now I'm looking into securing that connection. A common recommendation I see is to just use a self-signed server key, and embed the server's certificate directly within the client. This lets the app trust the server without requiring a cert download or third party CAs.
However, my understanding is that these certificates are only good for a year (per the openssl command to generate them). Wouldn't there be a problem in trying to renew the cert, when the old version is directly embedded in the client? I don't see how you could prepare the client for the new cert either, as both server and client would have to use the same cert for every request, right?
Given how often I see this method suggested, how do you get around the expiration problem?
Related
Situation: we can't update der file on the client's device. And the SSL certificate on our web server expires soon.
Is it possible to renew the server's SSL certificate without replacing the client's certificate?
We want to follow this guide: https://www.smashingmagazine.com/how-to-issue-a-new-ssl-certificate-with-an-old-ssl-key/
However, we are not sure if it helps.
The question is:
Does the der file (on the client side) contain only public key and it is safe to renew SSL certificate using the technique described in the link above (keeping same pub/private keys).
Will it work on client's device without replacing der file? Or der file contains not only the public key for SSL certificate but also some other information?
I'm afraid, but based on your original post and clarifications, client will expect from web server the same server certificate as stored in DER file on client device. Client performs exact binary copy comparison (not only public keys).
Any attempts to replace server certificate will result in a connection failure on client. If you plan to replace the certificate on web server, you will have to update client devices as well.
Unfortunately, there are a lot of flawed HPKP implementations (to be honest, didn't see any reliable implementation) that work fine until server certificate is changed. In order to properly handle server certificate replacement, client MUST be able to store at least two server certificates, existing and new one. Here is the high-level server certificate replacement process:
acquire new server certificate from CA in advance.
make application update by including new certificate side-by-side. When client updates the application on their device, client app will trust both, existing and new certificate.
give clients a time to make app update on their devices. Ideally, you should wait until all clients have updated app version with updated certificate.
change SSL certificate in server bindings.
after aa time you can make another update for client certificate by removing expired certificate from trust store.
only this step sequence may guarantee uninterrupted certificate pinning renewal.
I am trying to wrap my head around certificates and any help is appreciated. So far this is what I understand, please correct me if I am wrong.
When using the browser when I navigate to the https site the browser downloads the certificate(without the private key) and then continues to send the data over https?
I have come across some sites (especially when developing) that require you to install the certificate on the local machine before making a service call. What is the purpose here and how does it work?
I have also seen some scenarios where you need to install the certificate on the client machine for authentication purposes for example if you are using an email client, how does this work?
When using the browser when I navigate to the https site the browser downloads the certificate(without the private key) and then continues to send the data over https?
No, the browser and the server stablish a SSL/TLS secure channel with a symmetric encryption key. During the handshake process the server presents the https certificate and digitally signs some data with the private key as a proof of authenticity.
I have come across some sites (especially when developing) that require you to install the certificate on the local machine before making a service call. What is the purpose here and how does it work?
The client must trust the server certificate. Usually it has a list with the Certification Authorities for which certificates are accepted. For other certificates is needed to add them to the trust list. If not, the communication will be rejected
I have also seen some scenarios where you need to install the certificate on the client machine for authentication purposes for example if you are using an email client, how does this work?
Probably the same case as the previous one. Also the public part of the certificate of a user can be used to encrypt a message for him
I'm have an application deployed to salesforce on the force.com platform,
which I'm trying to configure a 2 way SSL for.
I.e.
I want that for each request sent to from SF to my server, a client certificate will be sent.
I did the necessary configurations on SF for the certificate to be sent, but I'm still getting 403.7 from the server, which means: forbidden, client certificate required.
I installed wireshark on the server, captured traffic to see the 2 way ssl handshake, and I'm trying to find in the server hello message where it tells the client the trusted CAs from which a client certificate should correspond, but I'm having difficulties finding it.
I suspect that's why the client does not send the certificate.
Can anyone point me to where in the server hello I should look? Or perhaps in another packet capture?
Thanks in advance.
Client Key Exchange record:
Here, the server sends its Certificate Request message and the client sends its Certificate message in response, but that message contains 0 certificates.
Typically, this happens when the client was unable to select a client certificate to use. Either it's not configured properly to make use of any certificate, or it can't find one that is issued by one of the acceptable CAs.
Look at the Certificate Request packet and check its certificate_authorities list. This is a list of the CA Distinguished Names (DNs) that the server is willing to accept.
One way or another, the client will need to find a client certificate with which it can build a chain towards of those DNs. In the simplest case, a client certificate issued by such a DN is available. Otherwise, the client could have to build a chain from a client cert to such a DN, it would need to have the necessary intermediate CA certificates to do so. (How this is done depends on the client's configuration mechanisms.)
If intermediate CA certificates are necessary and not available on the client side, you may need to configure your server to accept them and advertise them in the Certificate Request too.
Added a screenshot of the handshake captures. can you please point me to where I should be looking? –
See packet #31. It contains the Certificate Request. Also packet #33 contains the certificate from the client, so the reason is not the client does not send the certificate, but instead that the server either does not like the certificate because the validation failed or because the certificate is not sufficient as authorization for the requested resource. You might get more information from the servers log.
Not sure if this will help anyone else, but for our case of this issue everything was working when running locally in Visual Studio and in IIS, but when deployed to a real server, we were hitting a certificate issue during 2-way SSL as described above and verified in Wireshark.
Anyway, on that server we have also have a .NET 4.7.2 Console application which was calling the same API and everything was working fine.
But, our .NET 4.7.2 web API calls were failing. It appears that when the same code was running inside IIS the cert was not available during the SSL negotiation. (although it loaded fine)
Our solution at this point was to modify the following call to include the 3rd parameter.
certificate = new X509Certificate2(certificatepath, Password, X509KeyStorageFlags.MachineKeySet);
By default X509Certificate2 uses the UserKeySet option, so perhaps the application pool user or another thread in IIS (?) was having trouble accessing the cert for the negotiation.
Here are a couple of the related pages that I found useful during my research:
https://paulstovell.com/x509certificate2/
https://github.com/dotnet/runtime/issues/23437
For a project I'm working on I have to generate web server certificate.
As I understand it, server certificates should contain the Server Authentication OID (1.3.6.1.5.5.7.3.1). But as I see all server certificates issued by well known issuers like Verisign contain also Client Authentication OID (1.3.6.1.5.5.7.3.2).
I tried to use certificate with only server authentication OID - seems it works fine.
Questions
Why is the client authentication OID needed for server certificates?
Is it needed for some legacy support or there is another reason for it?
The difference between the two is exactly how they're described.
For using a certificate as a server (on the receiving end of the connection), it must have the Server extended key usage.
In a 2-way SSL connection, where the client (on the initiating end of the connection) presents a certificate back to the server, it must have the Client extended key usage.
If you're never using the certificate as a client cert, you won't need the Client Authentication OID.
I think it is also useful to point out that one of the main distinctions between Client and Server certificates is that:
Server Certificates are used for encryption and decryption of data;
Client Certificates represent a user identity. That is, to prove the client's identity to a remote server.
I am working on a website that exposes an xml gateway that clients can submit an xml request to and get an xml response in return. The website/company has been purchased by a larger organization and has been migrated into their infrastructure. The existing production site is using an ssl certificate by a particular certificate authority but the larger organization uses certificates issued by a different certificate authority. We have tried run a test with one of their clients and they are getting an SSL handshake error. The original developer says that the only way to get it to work is to restore the original SSL certificate and not to use the new ones. I am looking for some guidance or direction to diagnose this issue, so any help would be appreciated.
What the developer says, from the description is sensible to me, but the problem is theirs.
To verify that this is exactly what is happening you can do a wireshark capture and then decode the flow as SSL. If the problem is that the client do not trust the certificate send by the server and reject the connection you will see it in the handshake in the wireshark.
If you use a java client you could run it with -Djavax.net.debug=ssl to see the ssl messages from within java.
If this is indeed the problem then you must configure the client's truststore to have the certificate send by the server (which is the original one).
If this configuration is possible of course... This depends on the application
UPDATE:
Well if you migrated to a new CA, i.e. you deploy a new certificate in your interface, then sorry to say, it is "your" -meaning the server side- error.
IMHO, if it is possible, you should redeploy the old certificate for a prespecified period, communicating to all the stakeholders that you plan to migrate to a new certificate signed by a new CA, so that the clients don't break
Then it is their responsibility, within that period, to "fix" their client apps to be able to accept the new certificate. This can be as simple as configuration i.e. importing the certificate to a truststore, to as "complicated" as to change code and rebuild the client app (e.g. if the new issued certificate does not have extensions that the code is verifying or the CN has changed etc).
If it is not possible to redeploy the old certificate then, you just have to communicate the change to all stakeholders and then, they should "fix" it accordingly (as mentioned above)