I have web application, which is expired and renewed the same certificate and signed some part. Can it work?
Suppose I have a.jar, b.jar and c.jar in my WEB-INF\lib and all jars have same package. Those are signed with certificate C1. Now certificate (C1) is renewed and only c.jar is signed with renewed certificate. Can this work in web application?
Or how to renew certificate to work above case?
It is confirmed that all the jar files need to be signed again if certificate is renewed and if some jar is changed and built and signed with renewed certificate then all jar files need to be signed(Package is shared with other jar files which signed with older certificate.)
Related
Our UWP application will be released outside of the Microsoft Store since it is a Line-Of-Business application. I scoured the internet for references and what I have gathered is that for users to be able to install our UWP application, it needs to be signed with a Trusted Certificate.
A trusted certificate can be obtained from any Certificate Authority(CA) by submitting a Certificate-Signing-Request(CSR) for code signing cert.
Now I haven't tried to get a certificate yet, as it involves payments. So, I want to be sure if I can get a .pfx certificate from the Certificate Authorities for signing our UWP application?
Will CA have the provision to select a Code signing certificate for UWP? and NOT an SSL certificate?
Yes, you should sign your app with a code-signing certificate that is trusted on each device to which you deploy the app.
You would typically use a certificate that is provided by your organization if you belong to one. The other recommended option is to purchase a certificate from a third-party provider whose public root certificate is already trusted by Windows.
If you do a Bing or Google search for "code signing certificate", you should find some trusted providers.
I am implementing our project specific Certification Authority (CA).
I have meet with a case like renewing CA's certificate.
The problem is, We have very big system, and we are giving the Certs to Multiple components (we issues certs to thousands of entities).
So if we revoke the old cert directly at the time of renewing it is causing security issues.
For this we are following the process like, We just add a new certificate to out CA, and we will renew the certs of all the entity certs those were issued by the CA.
This process is working fine, but I have meet with small problem in publishing the CRL(As CRL is signed by the CA's certificate).
If we sign with the old Cert of CA, then already renewed entities are facing security issues,
If we sign with the new cert of CA, then the entities with old certs are facing security issues.
Renewal process of CA in my system will take a period of time.
In this case, I am proposing to publish 2 CRL's to the renewed CA.
But I am not sure that one can publish 2 CRL's for the same CA.
Please comment on above statement.
We have Web API 2 application exposed to outside vendors for various integrations. We're adding a new one with DocuSign through their Connect service and they will be signing their requests with their X509 certificate. I would rather not install the certificate on the server itself because we add new servers and deployments often based on load.
Here is my plan, and I'd like to know what the security risks are with it (assuming it will work at all).
DocuSign provides their X509 certificate for download. I want to place that *.cer file in my Web API application's ~/App_Data folder, along with any other certs from any other vendors. I will use a DelegatingHandler to grab the client certificate from the Request. I would then use the X509Chain class as described here to load all certificates from the ~/App_Data folder and to verify the request certificate.
From there I would map the certificate subject to a role and add that to the current thread to provide authentication for specific routes.
I've gathered from my research that this method would be less secure than installing DocuSign's certificate to the server's root store - is that correct? And how much less secure?
At the end of the day I'd like to (1) verify that the request is coming from who it says it's coming from, and (2) add roles based on the verified requester for authentication.
I just want to know that how Certificate revocation works in PingFederate.
From where it read about the expiration time of any certificate which are used by any connection? Is there a file which consists of all the information about the connection and respective certificates?
Is your main question about detecting when your certificates will expire? If so, details about Certificate Revocation List (CRL) functionality probably isn't what you want. CRL's indicate the serial #'s of the certificates that have been revoked before they have expired - and often expired ones are automatically removed from a CRL.
If you want to determine which certificates are close to expiring - you may have to check each connection. Here's an example of where to check if you are talking about your signing certificate on SP connections (if you are an IdP): https://support.pingidentity.com/s/document-item?bundleId=pingfederate-92&topicId=adminGuide%2FconfiguringDigitalSignatureSettings.html
There is no one central place to check the status of all certificates. If you believe certificates have expired and you are experiencing errors - consult the server.log file. See: https://support.pingidentity.com/s/document-item?bundleId=pingfederate-92&topicId=adminGuide%2FmanagingLogFiles.html
If you'd like to be notified when certificates are about to expire, you can enable Runtime Notifications to have PingFederate email you X # of days before a certificate expires: https://support.pingidentity.com/s/document-item?bundleId=pingfederate-92&topicId=adminGuide%2FconfiguringRuntimeNotifications.html
If all else fails - please contact our Customer Support: https://support.pingidentity.com. They will be happy to assist.
(Note: I work for Ping!)
The Expired certificates report Knowledgebase page shows that you can run
cd $PingFederate_Install_Directory>/pingfederate/server/default/data
keytool -list -v -keystore ping-dsig.jks < /dev/null
to get a dump of all the certificates, out of which you can parse expiry dates.
Warning:
The signer certificate has expired.
I get the following when I try to sign with jarsigner, and the output jar doesn't get generated.
How do I renew my jar signature?
Are you using a self-signed certificate? If so, you just need to use keytool to generate a new certificate, then sign your jar using keysigner.
If you are using a third-party signed certificate (Verisign, Thawte, etc), you'll need to renew your key using their online system (usually the same place you got the original cert).