How to request a ssl certificate with non-repudiation and data encipherment in IIS - ssl

I created a SSL certificate that I installed on an IIS webserver. This certificate only had Digital Signature and Key Encipherment but I need to include Non-Repudiation and Data Encipherment in the Key Usage as well.
Also, in the Extended Key Usage, I do NOT want TLS Web Server Authentication. How do I take that out from the certificate?
I understand that I need to create a brand new certificate since existing certificates cannot be changed and that's okay.
The question is, how do I include Non-Repudiation and Data Encipherment and exclude TLS Web Client Authentication from the new certificate?

Related

When/why would you need to use CACert in a TLS negotiation?

I am trying to understand the parameters used to configure TLS (specifically for rabbitmq but my question might be more general).
There are 4 main entities to consider:
Key - private key used by a peer to decrypt messages send to it that have been encrypted using its public key.
Cert - A certificate containing the peers public key
It also contains some identifying details like hostname, organisation etc. many of which are optional.
A certificate could be unsigned (rarely if ever?), self-signed or signed by a certificate authority.
CACert - the certificate of a CA trusted by the peer which can be used to decrypt and verify the signature of a signed cert.
CA-key - the private key of the CA which it used to sign a cert.
These map to configuration settings including:
enablePeerVerification - If true then a peer tries to verify the server is who it says it is by checking the certificate really was signed by the CA (and likewise up the chain of trust until it reaches a CA it trusts because it has a cert in its local CA trust store).
It is a bad idea to set this to false as someone could impersonate the peer.
(in go this option is called InsecureSkipVerify as a warning)
If the cert is self-signed, peer verification is impossible.
This option allows you to use a peer's self-signed cert instead
at your own risk (e.g. during development).
Key - the private key used for decryption
Cert - used for encryption (and handshaking)
CACert - the certificate of the CA who signed the "Cert" certificate
Why are there configuration settings for the CACert?
If the cert is signed by a CA then it already contains enough information to locate the CA (e.g. domain name). What is the CACert for and if or when is it sent during TLS negotiation?
Is this just a convenience to save going off to the CA directly?
You will still have to do this if the CACert does not match or point to one in your trust store.
The settings I'm referring to are "cacert" in the rabbitmq.config for the server and amqp_ssl_socket_set_cacert() in the C API (rabbitmq-c).
I would like to check that my understanding is correct (https://xkcd.com/386/)
First the CA private key here is irrelevant here since by definition it is private and hence you never have it, except if you do self signed certificates.
The TLS handshake is:
the server you are connecting to sends you its certificate and, optionnally, a list of intermediate certificates up to the root (CA), that last one being also optional and often not sent as the client is supposed to have it already in its truststore
if the server requests a client certificate it sends the list of CAs it will accept for the client certificate (it is an hint to help the client choose the proper certificate to send)
so if it needs to, the client sends its certificate and in the same way as first point, a potential list of intermediate certificates up to some root.
Depending on the client you may then have multiple configuration items:
- the list of certificates to send as intermediate (either as a path to some directory or a single file with all of them in it) together with its own client certificate
- the list of certificates you use (again a directory or a file) as fully trusted to verify the server certificate.
Often, these two settins are only one.
Now:
If the cert is signed by a CA then it already contains enough information to locate the CA (e.g. domain name).
Not sure to understand you, but in general no. First a certificate is not necessarily/only for a domain name it can be for other things. Then a certificate is typically signed by an intermediate, not directly by the CA. So I am not sure how you want to locate the CA?

Why is SSL certificate pinning required?

I'm not quite understanding the necessity of certificate pinning in highly sercure SSL connection establishment(to avoid Man in the Middle attacks).
SSL cert pinning requires embedding original server certificate in the host to verify with the one presented by server. what is the difference between the server certificate embedded in the host and the one presented by server to be validated by client?
What is that I am missing here?
what is the difference between the server certificate embedded in the host and the one presented by server to be validated by client?
There should be none and that's exactly the point of certificate pinning.
Without certificate pinning an application commonly accepts any certificate which matches the requested hostname and is issued by a locally trusted CA (certificate authority). Given that there are usually more than 100 CA in the local trust store it is sufficient that one of these got successfully attacked as in the case of DigiNotar in 2011. Thus it makes sense to limit the certificate you accept to a specific one, i.e. pinning.
Besides the certificate pinning by comparing the certificate received with a locally stored certificate there are other ways of pinning: for example one might just check against a fingerprint (hash) and not the full certificate. In case the certificate can expire it might be more useful to check only the public key and not the whole certificate because the public key is often kept on certificate renewal. Or one might pin to a specific CA which one considers trusted to issue certificates for this domain.
Note that to understand pinning you might need to understand how the authentication of the server works. One part of this is that the server certificate is validated (hostname, expiration, trust chain ...). But this is not enough since the certificate itself is public, i.e. everybody can get it and could send it inside the TLS handshake. Thus the other major part of the authentication is that the server proves that it is the owner of the certificate. This is done by signing some data using the private key matching the certificate. Since only the owner of the certificate should have the private key this proves ownership. Because of this anybody could embed the servers certificate for pinning but only the server itself can prove ownership of the certificate.

Is it possible to revoke a valid SSL certificate

Our client is asking us to migrate a list of internal facing Java projects to use SSL for making potentially sensitive REST calls. They are planning to generate and sign the certificates internally.
I am concerned that in case a certificate is ever compromised, an application might wish to revoke their certificate.
Is it possible to revoke certificates programmatically without changing the master? It seems once the hash signature is established, there would be no way to revoke it, but then how do agencies like Verisign do it?
The certificates include as part of their information how to check revocation, normally a CRL (Certificate Revocation List) or online service OCSP (Online Certificate Status Protocol)
A certification service provider revoke a certificate by including it in the CRL and its OCSP service. When the customer wants to check revocation of a certificate download the CRL to check or performs an OCSP request
To that could be done you would need:
1) Have a OCSP service and / or CRL
2) Include in the self-generated certificate the URL to OCSP/CRL.
3) Revoke certificates including them in the list of your revocation service
For example, for secure HTTPS websites the browser is responsible for performing revocation checking. However Google decided in 2012 to default Chrome not to check for certificate revocation on non-EV certificates
Therefore, be aware that control of revocation is client responsibility and could not do
Revoking a certificate without deleting the certificate authority that signed that certificate is one of the basics of working with certificates.
As explained above, there are two ways to check if a certificate is revoked: by checking with a dedicated server (OCSP) or by checking a static file that you download every so often (CRL).
You can setup a test OCSP server easily using openssl.
And you can also generate a CRL file using openssl. A CRL file looks a bit like a certificate or a csr (usually kept in base 64). You can use an online CRL decoder here:
http://developerutils.com/CRLDecoder.php

OpenSSL client certificates vs server certificates

I have some basic questions on certificates. Let me first explain my understanding on SSL authentication.
SSL/TLS basically has two main things,
Authentication - to make sure we are communicating to the correct party on both end.
Encryption - encrypt the actual data transferred between both end.
Certificates have the public key and some additional information. SSL communication between Client (say 'C') and Server (say 'S') works like this,
C initiates the request to S.
S sends its public key to C.
C verifies the identity of S. (Server identity verification or server authentication)
C sends its public key to S.
S verifies the identity of C. (Client identity verification or client authentication)
C generates symmetric or session key (say 'K') and encrypt it with S public key and send it to the server.
Now both C and S have the shared symmetric key which will be used for encrypting the data.
Here I believe steps 4 and 5 meant for Client Authentication is optional. Correct me If I am wrong.
Steps 1 to 5 involves asymmetric mode of encryption i.e only for 'Authentication' and after that it involves symmetric mode of encryption for actual data transfer between them.
My questions are as follows,
I have read from this link (related to IIS server) that there are two types of Certificates. One is client certificate and the other is server certificate. I thought the one in the client side who initiates the request is client certificate and the other is server certificate. What is the difference between client and server certificate w.r.to OpenSSL ?. Is there any difference in CN name in these certificates w.r.to OpenSSL ?
I was asked to use Client Certificates for authentication. Does it mean that we are bypassing server authentication and using only client certificates for authentication ?. I don't think so. As per my understanding, client authentication should be done in addition to the server authentication. Correct me if I am wrong here.
Server Certificates:
Server Certificates are identitiy of a Server to presented by it during SSL handshake.
Typically they are issued by a certificate authority (CA) well known to client, The basis on which the certificate is issued is possession of some publicly known Identifier of that server, for Webserver its the Hostname of the server, which is used to reach server
Example:- http://blog.8zero2.in/
Server certifictae
Server Certificates Purpose
clearly mention by the x509 extension parameter
Certificate Key usage
1. Signing
2. Key Encipherment
Signing :- It means that the key in the certificate can be used to prove the Identity of the server mentioned in the CN of the cerificate , that is entity Authentication .
Key Encipherment :- It means the key in the in the ceritificate can be used to encrypt the session key ( symmetic key ) derived for the session
Client Certificate :-
Client certificates as the name indicates are used to identify a client or a user.
They are meant for authenticating the client to the server.
Purpose of holding a client certificate varies
It may represent possession of email address or Mac-address , usually mapped to the serial number of the certificate
Client Certificates Purpose
clearly mention by the x509 extension parameter
Certificate Key usage
1. Signing
1) The article you link is a good one :-). To put it another way: there is a field in the certificate that says what use(s) it is allowed to be used for. When you create/request a certificate, you are asking for a certificate for a particular use, and the CA signs it on that basis.
It is more secure to use different certificates for different purposes and to ensure that each certificate can only be used for its intended purpose. (Or if you want to be cynical, CAs make you buy separate client and server certs so they get more sales.)
For instance, you might want your web server to be able to identify itself as your company for serving purposes, but not want that same certificate to be able to be used to sign outgoing connections to other businesses.
2) You are correct.

what is Data Encipherment in a ssl certificate [closed]

Can someone please point me to good articles on understanding the 'key usage' property of a ssl certificate? what are the pros and cons of getting a certificate issued with 'Data Encipherment' as one of the values?
Is this recommended? Recently we had to host a web service on our site, to be consumed by a third party and one of their requirements is that the certificate must have 'Data encipherment' in 'key usage'. Currently our site already has ssl, but key usage doesn't have 'data encipherment'.
Will there be any noticeable slowness if say we buy a new certificate with data encipherment and replace the current site certificate with the new one?
You can read the spec, RFC 5280 4.2.1.3. Basically Key Usage is just bits set on the certificate that restrict what the certificate authority certifies using the key for. It should not affect SSL performance - I don't believe SSL even allows for Data Encipherment (using the public key to encrypt data versus using it to establish a symmetric key for data).

Resources