[HELP NEEDED] External CA configuration for Dogtag
Hello, I am an engineer from India and I have been struggling with this for the past 2 weeks. Request you to help me out. *USE-CASE: * Dogtag is the private CA for multiple services in a cluster. Trust is established by providing the root certificate of dogtag to all the services. What happens if dogtag crashes? All the services will have to be given the root certificate of the new dogatg. How can we avoid this? Can we bring up multiple instances dogtag with a static certificate every time? The only way I could find is by using the* external CA* option. I am following the 2-step pkispawn process with 2 config files (deployment-1.cfg and deployment-2.cfg) In the first step the csr is generated. I take the csr and get a certificate from the external CA and place it in the required location. The root certificate of the CA has also been placed in the required location. Step 2 of pkispawn goes through and the ca_admin cert is generated and signed. However, when i make a REST call to list the certificates, I get 2 different errors: (Please note that I replicated the same steps with same files on 2 setups and got 2 errors) curl -k --request GET https://localhost:9443/ca/rest/certs *ERROR 1* <?xml version="1.0" encoding="UTF-8"
standalone="yes"?><PKIException><ClassName>com.netscape.certsrv.base.PKIException</ClassName><Code>500</Code><Message>Error listing certs in CertsResourceService.listCerts!</Message><Attributes/></PKIException> *ERROR 2* With the same steps i also get a NullPointerException as well (Attached logs - null-pointer-error.txt) When i see the status of my pki-instance after pkispawn step-2, It says the Instance is loaded and needs to be configured. (attched logs : post-pkispawn-2.txt) However it starts using systemctl without any errors I suspect I am missing some part in the configuration. Any help/pointers would be very helpful! Thanks Kritee *Attached files : * deployment-1.txt - config file for pkispawn step 1 deployment-2.txt - config file for pkispawn step 2 pkispawn-1-log.txt - logs for pkisppawn step 1 pkispan-2-log.txt - logs for pkispawn step 2 dogtag-cert.txt - root certificate of dogtag generated by external CA ca-admin-cert.txt - admin cert signed by dogtag null-pointer-error.txt - null pointer exception while making a REST call to list certs post-pkispawn-2.txt - status of pki-instance after pkispawn step 2
Hello, I am an engineer from India and I have been struggling with this for the past 2 weeks. Request you to help me out. *USE-CASE: * Dogtag is the private CA for multiple services in a cluster. Trust is established by providing the root certificate of dogtag to all the services. What happens if dogtag crashes? All the services will have to be given the root certificate of the new dogatg. How can we avoid this? Can we bring up multiple instances dogtag with a static certificate every time? The only way I could find is by using the* external CA* option. I am following the 2-step pkispawn process with 2 config files (deployment-1.cfg and deployment-2.cfg) In the first step the csr is generated. I take the csr and get a certificate from the external CA and place it in the required location. The root certificate of the CA has also been placed in the required location. Step 2 of pkispawn goes through and the ca_admin cert is generated and signed. However, when i make a REST call to list the certificates, I get 2 different errors: (Please note that I replicated the same steps with same files on 2 setups and got 2 errors) curl -k --request GET https://localhost:9443/ca/rest/certs *ERROR 1* <?xml version="1.0" encoding="UTF-8"
standalone="yes"?><PKIException><ClassName>com.netscape.certsrv.base.PKIException</ClassName><Code>500</Code><Message>Error listing certs in CertsResourceService.listCerts!</Message><Attributes/></PKIException> *ERROR 2* With the same steps i also get a NullPointerException as well (Attached logs - null-pointer-error.txt) When i see the status of my pki-instance after pkispawn step-2, It says the Instance is loaded and needs to be configured. (attched logs : post-pkispawn-2.txt) However it starts using systemctl without any errors I suspect I am missing some part in the configuration. Any help/pointers would be very helpful! Thanks Kritee *Attached files : * deployment-1.txt - config file for pkispawn step 1 deployment-2.txt - config file for pkispawn step 2 pkispawn-1-log.txt - logs for pkisppawn step 1 pkispan-2-log.txt - logs for pkispawn step 2 dogtag-cert.txt - root certificate of dogtag generated by external CA ca-admin-cert.txt - admin cert signed by dogtag null-pointer-error.txt - null pointer exception while making a REST call to list certs post-pkispawn-2.txt - status of pki-instance after pkispawn step 2
The CA needs to generate or sign certificates for other servers- e.g. a web server. Clients of those servers should trust the CA's certificate as the CA certificate that signs the server certificates. They don't need to communicate with the CA directly. (The exception might be if the CA is also an online certificate revocation server - but that is beyond my experience.) You should assume that your CA will eventually crash- or that you might make a configuration change or an update that you want to roll back. As with any server, you should back up the critical files. if this is a virtual machine, it makes backing up the entire machine much easier. I wouldn't imagine that the entire CA configuration and database directories are very big. On 10/10/14 07:18, kritee jhawar wrote:
Hello,
I am an engineer from India and I have been struggling with this for the past 2 weeks. Request you to help me out.
*USE-CASE: *
Dogtag is the private CA for multiple services in a cluster. Trust is established by providing the root certificate of dogtag to all the services. What happens if dogtag crashes? All the services will have to be given the root certificate of the new dogatg.
How can we avoid this?
Can we bring up multiple instances dogtag with a static certificate every time?
The only way I could find is by using the*external CA* option.
I am following the 2-step pkispawn process with 2 config files (deployment-1.cfg and deployment-2.cfg)
In the first step the csr is generated. I take the csr and get a certificate from the external CA and place it in the required location. The root certificate of the CA has also been placed in the required location. Step 2 of pkispawn goes through and the ca_admin cert is generated and signed.
However, when i make a REST call to list the certificates, I get 2 different errors:
(Please note that I replicated the same steps with same files on 2 setups and got 2 errors)
curl -k --request GET https://localhost:9443/ca/rest/certs
*_ERROR 1_*
<?xml version="1.0" encoding="UTF-8"
standalone="yes"?><PKIException><ClassName>com.netscape.certsrv.base.PKIException</ClassName><Code>500</Code><Message>Error listing certs in CertsResourceService.listCerts!</Message><Attributes/></PKIException>
*_ERROR 2_*
With the same steps i also get a NullPointerException as well (Attached logs - null-pointer-error.txt)
When i see the status of my pki-instance after pkispawn step-2, It says the Instance is loaded and needs to be configured. (attched logs : post-pkispawn-2.txt) However it starts using systemctl without any errors
I suspect I am missing some part in the configuration.
Any help/pointers would be very helpful!
Thanks
Kritee
*Attached files : *
deployment-1.txt - config file for pkispawn step 1
deployment-2.txt - config file for pkispawn step 2
pkispawn-1-log.txt - logs for pkisppawn step 1
pkispan-2-log.txt - logs for pkispawn step 2
dogtag-cert.txt - root certificate of dogtag generated by external CA
ca-admin-cert.txt - admin cert signed by dogtag
null-pointer-error.txt- null pointer exception while making a REST call to list certs
post-pkispawn-2.txt - status of pki-instance after pkispawn step 2
_______________________________________________ Pki-users mailing list Pki-users@redhat.com https://www.redhat.com/mailman/listinfo/pki-users
Hi Thanks for the response.I am inline with what you said, that the clients just need to trust the CA and need not communicate with it. However my clients are physical devices which will need the trust store burnt into them which is why i need to have a constant trust chain. External CA seems like the best way to go. Please let me know if you could figure out why my configuartion won't go through with the data I have provided. Regards Kritee On Fri, Oct 10, 2014 at 6:13 PM, Gaiseric Vandal <gaiseric.vandal@gmail.com> wrote:
The CA needs to generate or sign certificates for other servers- e.g. a web server. Clients of those servers should trust the CA's certificate as the CA certificate that signs the server certificates. They don't need to communicate with the CA directly. (The exception might be if the CA is also an online certificate revocation server - but that is beyond my experience.)
You should assume that your CA will eventually crash- or that you might make a configuration change or an update that you want to roll back. As with any server, you should back up the critical files. if this is a virtual machine, it makes backing up the entire machine much easier.
I wouldn't imagine that the entire CA configuration and database directories are very big.
On 10/10/14 07:18, kritee jhawar wrote:
Hello,
I am an engineer from India and I have been struggling with this for the past 2 weeks. Request you to help me out.
*USE-CASE: *
Dogtag is the private CA for multiple services in a cluster. Trust is established by providing the root certificate of dogtag to all the services. What happens if dogtag crashes? All the services will have to be given the root certificate of the new dogatg.
How can we avoid this?
Can we bring up multiple instances dogtag with a static certificate every time?
The only way I could find is by using the* external CA* option.
I am following the 2-step pkispawn process with 2 config files (deployment-1.cfg and deployment-2.cfg)
In the first step the csr is generated. I take the csr and get a certificate from the external CA and place it in the required location. The root certificate of the CA has also been placed in the required location. Step 2 of pkispawn goes through and the ca_admin cert is generated and signed.
However, when i make a REST call to list the certificates, I get 2 different errors:
(Please note that I replicated the same steps with same files on 2 setups and got 2 errors)
curl -k --request GET https://localhost:9443/ca/rest/certs
*ERROR 1*
<?xml version="1.0" encoding="UTF-8"
standalone="yes"?><PKIException><ClassName>com.netscape.certsrv.base.PKIException</ClassName><Code>500</Code><Message>Error listing certs in CertsResourceService.listCerts!</Message><Attributes/></PKIException>
*ERROR 2*
With the same steps i also get a NullPointerException as well (Attached logs - null-pointer-error.txt)
When i see the status of my pki-instance after pkispawn step-2, It says the Instance is loaded and needs to be configured. (attched logs : post-pkispawn-2.txt) However it starts using systemctl without any errors
I suspect I am missing some part in the configuration.
Any help/pointers would be very helpful!
Thanks
Kritee
*Attached files : *
deployment-1.txt - config file for pkispawn step 1
deployment-2.txt - config file for pkispawn step 2
pkispawn-1-log.txt - logs for pkisppawn step 1
pkispan-2-log.txt - logs for pkispawn step 2
dogtag-cert.txt - root certificate of dogtag generated by external CA
ca-admin-cert.txt - admin cert signed by dogtag
null-pointer-error.txt - null pointer exception while making a REST call to list certs
post-pkispawn-2.txt - status of pki-instance after pkispawn step 2
_______________________________________________ Pki-users mailing listPki-users@redhat.comhttps://www.redhat.com/mailman/listinfo/pki-users
_______________________________________________ Pki-users mailing list Pki-users@redhat.com https://www.redhat.com/mailman/listinfo/pki-users
Hi After a little more debugging came to the conclusion that post external CA configuration there seems to be some issue with the directory service Upon making a rest call to list the certs, I get an LDAP exception with 'Bad Search Filter' message. Has anyone faced this? Regards Kritee On Sat, Oct 11, 2014 at 10:15 AM, kritee jhawar <kriteejhawar@gmail.com> wrote:
Hi
Thanks for the response.I am inline with what you said, that the clients just need to trust the CA and need not communicate with it. However my clients are physical devices which will need the trust store burnt into them which is why i need to have a constant trust chain. External CA seems like the best way to go. Please let me know if you could figure out why my configuartion won't go through with the data I have provided.
Regards Kritee
On Fri, Oct 10, 2014 at 6:13 PM, Gaiseric Vandal < gaiseric.vandal@gmail.com> wrote:
The CA needs to generate or sign certificates for other servers- e.g. a web server. Clients of those servers should trust the CA's certificate as the CA certificate that signs the server certificates. They don't need to communicate with the CA directly. (The exception might be if the CA is also an online certificate revocation server - but that is beyond my experience.)
You should assume that your CA will eventually crash- or that you might make a configuration change or an update that you want to roll back. As with any server, you should back up the critical files. if this is a virtual machine, it makes backing up the entire machine much easier.
I wouldn't imagine that the entire CA configuration and database directories are very big.
On 10/10/14 07:18, kritee jhawar wrote:
Hello,
I am an engineer from India and I have been struggling with this for the past 2 weeks. Request you to help me out.
*USE-CASE: *
Dogtag is the private CA for multiple services in a cluster. Trust is established by providing the root certificate of dogtag to all the services. What happens if dogtag crashes? All the services will have to be given the root certificate of the new dogatg.
How can we avoid this?
Can we bring up multiple instances dogtag with a static certificate every time?
The only way I could find is by using the* external CA* option.
I am following the 2-step pkispawn process with 2 config files (deployment-1.cfg and deployment-2.cfg)
In the first step the csr is generated. I take the csr and get a certificate from the external CA and place it in the required location. The root certificate of the CA has also been placed in the required location. Step 2 of pkispawn goes through and the ca_admin cert is generated and signed.
However, when i make a REST call to list the certificates, I get 2 different errors:
(Please note that I replicated the same steps with same files on 2 setups and got 2 errors)
curl -k --request GET https://localhost:9443/ca/rest/certs
*ERROR 1*
<?xml version="1.0" encoding="UTF-8"
standalone="yes"?><PKIException><ClassName>com.netscape.certsrv.base.PKIException</ClassName><Code>500</Code><Message>Error listing certs in CertsResourceService.listCerts!</Message><Attributes/></PKIException>
*ERROR 2*
With the same steps i also get a NullPointerException as well (Attached logs - null-pointer-error.txt)
When i see the status of my pki-instance after pkispawn step-2, It says the Instance is loaded and needs to be configured. (attched logs : post-pkispawn-2.txt) However it starts using systemctl without any errors
I suspect I am missing some part in the configuration.
Any help/pointers would be very helpful!
Thanks
Kritee
*Attached files : *
deployment-1.txt - config file for pkispawn step 1
deployment-2.txt - config file for pkispawn step 2
pkispawn-1-log.txt - logs for pkisppawn step 1
pkispan-2-log.txt - logs for pkispawn step 2
dogtag-cert.txt - root certificate of dogtag generated by external CA
ca-admin-cert.txt - admin cert signed by dogtag
null-pointer-error.txt - null pointer exception while making a REST call to list certs
post-pkispawn-2.txt - status of pki-instance after pkispawn step 2
_______________________________________________ Pki-users mailing listPki-users@redhat.comhttps://www.redhat.com/mailman/listinfo/pki-users
_______________________________________________ Pki-users mailing list Pki-users@redhat.com https://www.redhat.com/mailman/listinfo/pki-users
On 10/10/2014 07:14 AM, kritee jhawar wrote:
Dogtag is the private CA for multiple services in a cluster. Trust is established by providing the root certificate of dogtag to all the services. What happens if dogtag crashes? All the services will have to be given the root certificate of the new dogatg.
How can we avoid this?
Why do you need to re-provision the services with a new root certificate if Dogtag crashes? Why not just restart the Dogtag instance with the existing certs? It sounds like you're throwing away the old instance and creating a new Dogtag instance needlessly. Also, I don't understand why your services won't run if Dogtag isn't currently running (unless you're using OCSP). Dogtag provisions certs, a service using a cert issued by Dogtag doesn't need to communicate with Dogtag unless you're using OCSP). As long as your services have been provisioned with the certs issued by Dogtag they should run fine (or are you issuing very short duration certs that need constant refreshing?) FWIW, what you describe, re-provisioning of a new CA cert is exactly identical to handling an expired CA cert. There was documentation written up recently on how to handle expiring CA certs but I don't have a pointer to it, sorry. But as I mentioned above I don't you need to replace the certs, you just need to restart the service. If the instance is crashing then that's a bug that needs fixing. Please file a bug report so the problem can get fixed. Ade can comment on the specific errors you reported. -- John
Thanks for the response I got the setup to work with external CA just yesterday. This time I used a dogtag as the external CA rather than OpenSSL and Microsoft. I'll have multiple instances of dogtag in my deployment. Ideally I want all of them to come up with these root certificate. Is there some location I can place a public private key pair wich dogtag uses to come up ? Also what I meant by services not coming up was not other components like KRA and DRM. I just have the CA subsystem and even though it was getting spawned wo were unable to use it. Thanks Kritee Sent from my iPhone
On 16-Oct-2014, at 00:44, John Dennis <jdennis@redhat.com> wrote:
On 10/10/2014 07:14 AM, kritee jhawar wrote: Dogtag is the private CA for multiple services in a cluster. Trust is established by providing the root certificate of dogtag to all the services. What happens if dogtag crashes? All the services will have to be given the root certificate of the new dogatg.
How can we avoid this?
Why do you need to re-provision the services with a new root certificate if Dogtag crashes? Why not just restart the Dogtag instance with the existing certs? It sounds like you're throwing away the old instance and creating a new Dogtag instance needlessly.
Also, I don't understand why your services won't run if Dogtag isn't currently running (unless you're using OCSP). Dogtag provisions certs, a service using a cert issued by Dogtag doesn't need to communicate with Dogtag unless you're using OCSP). As long as your services have been provisioned with the certs issued by Dogtag they should run fine (or are you issuing very short duration certs that need constant refreshing?)
FWIW, what you describe, re-provisioning of a new CA cert is exactly identical to handling an expired CA cert. There was documentation written up recently on how to handle expiring CA certs but I don't have a pointer to it, sorry. But as I mentioned above I don't you need to replace the certs, you just need to restart the service.
If the instance is crashing then that's a bug that needs fixing. Please file a bug report so the problem can get fixed.
Ade can comment on the specific errors you reported.
-- John
On Thu, 2014-10-16 at 07:21 +0530, Kritee Jhawar wrote:
Thanks for the response
I got the setup to work with external CA just yesterday. This time I used a dogtag as the external CA rather than OpenSSL and Microsoft.
OK, I suspected that the cert being used as the external CA cert was the problem. As I recall, there is a current bug being fixed to address issues with Microsoft issued CA certs. If you can use a dogtag cert as your external CA, then you'll avoid any issues.
I'll have multiple instances of dogtag in my deployment. Ideally I want all of them to come up with these root certificate. Is there some location I can place a public private key pair wich dogtag uses to come up ?
I don't understand what you are trying to do here. You have created several dogtag CA's that are subordinate to the external CA. They are CA's in their own right, with their own signing certificates. Why do they need access to the root CA? If you want several CA's with exactly the same signing cert, then you want clones.
Also what I meant by services not coming up was not other components like KRA and DRM. I just have the CA subsystem and even though it was getting spawned wo were unable to use it.
Thanks Kritee
Sent from my iPhone
On 16-Oct-2014, at 00:44, John Dennis <jdennis@redhat.com> wrote:
On 10/10/2014 07:14 AM, kritee jhawar wrote: Dogtag is the private CA for multiple services in a cluster. Trust is established by providing the root certificate of dogtag to all the services. What happens if dogtag crashes? All the services will have to be given the root certificate of the new dogatg.
How can we avoid this?
Why do you need to re-provision the services with a new root certificate if Dogtag crashes? Why not just restart the Dogtag instance with the existing certs? It sounds like you're throwing away the old instance and creating a new Dogtag instance needlessly.
Also, I don't understand why your services won't run if Dogtag isn't currently running (unless you're using OCSP). Dogtag provisions certs, a service using a cert issued by Dogtag doesn't need to communicate with Dogtag unless you're using OCSP). As long as your services have been provisioned with the certs issued by Dogtag they should run fine (or are you issuing very short duration certs that need constant refreshing?)
FWIW, what you describe, re-provisioning of a new CA cert is exactly identical to handling an expired CA cert. There was documentation written up recently on how to handle expiring CA certs but I don't have a pointer to it, sorry. But as I mentioned above I don't you need to replace the certs, you just need to restart the service.
If the instance is crashing then that's a bug that needs fixing. Please file a bug report so the problem can get fixed.
Ade can comment on the specific errors you reported.
-- John
Thanks a lot All this while I was using a Microsoft external CA. One more doubt I had: Do we have a way we're we can just provide a public private keypaor in a particular location and dogtag will always use that as root cert? Something like providing a static root certificate ? Regards Kritee
On Thursday, 16 October 2014, Ade Lee <alee@redhat.com> wrote: On Thu, 2014-10-16 at 07:21 +0530, Kritee Jhawar wrote:
Thanks for the response
I got the setup to work with external CA just yesterday. This time I used a dogtag as the external CA rather than OpenSSL and Microsoft.
OK, I suspected that the cert being used as the external CA cert was the problem. As I recall, there is a current bug being fixed to address issues with Microsoft issued CA certs. If you can use a dogtag cert as your external CA, then you'll avoid any issues.
I'll have multiple instances of dogtag in my deployment. Ideally I want all of them to come up with these root certificate. Is there some location I can place a public private key pair wich dogtag uses to come up ?
I don't understand what you are trying to do here. You have created several dogtag CA's that are subordinate to the external CA. They are CA's in their own right, with their own signing certificates. Why do they need access to the root CA?
If you want several CA's with exactly the same signing cert, then you want clones.
Also what I meant by services not coming up was not other components like KRA and DRM. I just have the CA subsystem and even though it was getting spawned wo were unable to use it.
Thanks Kritee
Sent from my iPhone
On 16-Oct-2014, at 00:44, John Dennis <jdennis@redhat.com> wrote:
On 10/10/2014 07:14 AM, kritee jhawar wrote: Dogtag is the private CA for multiple services in a cluster. Trust is established by providing the root certificate of dogtag to all the services. What happens if dogtag crashes? All the services will have to be given the root certificate of the new dogatg.
How can we avoid this?
Why do you need to re-provision the services with a new root certificate if Dogtag crashes? Why not just restart the Dogtag instance with the existing certs? It sounds like you're throwing away the old instance and creating a new Dogtag instance needlessly.
Also, I don't understand why your services won't run if Dogtag isn't currently running (unless you're using OCSP). Dogtag provisions certs, a service using a cert issued by Dogtag doesn't need to communicate with Dogtag unless you're using OCSP). As long as your services have been provisioned with the certs issued by Dogtag they should run fine (or are you issuing very short duration certs that need constant refreshing?)
FWIW, what you describe, re-provisioning of a new CA cert is exactly identical to handling an expired CA cert. There was documentation written up recently on how to handle expiring CA certs but I don't have a pointer to it, sorry. But as I mentioned above I don't you need to replace the certs, you just need to restart the service.
If the instance is crashing then that's a bug that needs fixing. Please file a bug report so the problem can get fixed.
Ade can comment on the specific errors you reported.
-- John
Thanks a lot All this while I was using a Microsoft external CA. Another doubt I had: Do we have a way we're we can just provide a public private key pair in a particular location and dogtag will always use that as root cert? Something like providing a static root certificate ? Regards Kritee On Thursday, 16 October 2014, Ade Lee <alee@redhat.com> wrote:
On Thu, 2014-10-16 at 07:21 +0530, Kritee Jhawar wrote:
Thanks for the response
I got the setup to work with external CA just yesterday. This time I used a dogtag as the external CA rather than OpenSSL and Microsoft.
OK, I suspected that the cert being used as the external CA cert was the problem. As I recall, there is a current bug being fixed to address issues with Microsoft issued CA certs. If you can use a dogtag cert as your external CA, then you'll avoid any issues.
I'll have multiple instances of dogtag in my deployment. Ideally I want all of them to come up with these root certificate. Is there some location I can place a public private key pair wich dogtag uses to come up ?
I don't understand what you are trying to do here. You have created several dogtag CA's that are subordinate to the external CA. They are CA's in their own right, with their own signing certificates. Why do they need access to the root CA?
If you want several CA's with exactly the same signing cert, then you want clones.
Also what I meant by services not coming up was not other components like KRA and DRM. I just have the CA subsystem and even though it was getting spawned wo were unable to use it.
Thanks Kritee
Sent from my iPhone
On 16-Oct-2014, at 00:44, John Dennis <jdennis@redhat.com <javascript:;>> wrote:
On 10/10/2014 07:14 AM, kritee jhawar wrote: Dogtag is the private CA for multiple services in a cluster. Trust is established by providing the root certificate of dogtag to all the services. What happens if dogtag crashes? All the services will have to be given the root certificate of the new dogatg.
How can we avoid this?
Why do you need to re-provision the services with a new root certificate if Dogtag crashes? Why not just restart the Dogtag instance with the existing certs? It sounds like you're throwing away the old instance and creating a new Dogtag instance needlessly.
Also, I don't understand why your services won't run if Dogtag isn't currently running (unless you're using OCSP). Dogtag provisions certs, a service using a cert issued by Dogtag doesn't need to communicate with Dogtag unless you're using OCSP). As long as your services have been provisioned with the certs issued by Dogtag they should run fine (or are you issuing very short duration certs that need constant refreshing?)
FWIW, what you describe, re-provisioning of a new CA cert is exactly identical to handling an expired CA cert. There was documentation written up recently on how to handle expiring CA certs but I don't have a pointer to it, sorry. But as I mentioned above I don't you need to replace the certs, you just need to restart the service.
If the instance is crashing then that's a bug that needs fixing. Please file a bug report so the problem can get fixed.
Ade can comment on the specific errors you reported.
-- John
participants (5)
-
Ade Lee -
Gaiseric Vandal -
John Dennis -
Kritee Jhawar -
kritee jhawar