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.
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.
According to the Identityserver4 documentation the AddDeveloperSigningCredential is, as the name implies, for development purposes only. I have found several articles that describe the process of switching to other signing certificates that are more geared towards production environments. My question is why is the switch necessary? Are the generated developer signing credentials insecure in some way, and if so what is the attack vector that can be exploited? What if I am running my identity server through an nginx reverse proxy and using an aws cloud signing credential through a load balancer? Does that adequately resolve the exposed attack vector? In short what risks are there to using developer signing credentials in production?
The generated RSA key (2k) is from a security point of view totally fine - you won't get "bad crypto" compared to a "production key".
The main problem with the dev signing key is that it is loaded from the local hard-disk - and especially (by default) from the application directory.
You should have a more secure storage location for keys (e.g. the Windows certificate store or some storage service) so that in case an attacker can read files from the app server hard disk cannot easily recover the private key.
I’m building a web application where users can create their own websites. Users have the option to point their own domain names at these sites. A prototype for the application already exists; Apache accepts requests on all hostnames and the actual domain mapping and resolution happen at the application level (a simple database lookup grabs the site that matches the requested hostname).
Where I’m stuck is how users’ SSL certificates might fit into this equation. What steps would I need to take to allow a user to upload their SSL certificate such that the application could successfully handle secure HTTP requests to their hostname? Is this even something the application alone could handle?
I think you cannot handle this in your application alone.
It's a CA problem, except you are an intermediate CA company, or you cannot get the user's domain SSL certificate and sign for user's domain.
The typical user, and IMHO even more the user's who are going to create a web site of this system as opposed to setting up their own WordPress or other site on their own server (or their own paid shared server hosting account), will have absolutely no idea how to setup a proper SSL certificate, so getting it to your securely so that you can install it wouldn't even be an issue because they will never get that far.
However, you should be able to use Let's Encrypt to do exactly what you need. As part of the process of adding a domain, once the domain is pointing to your server (the users will have to figure out how to do that with their domain registrar), you can create a Let's Encrypt certificate and validate it. My favorite web hosting company (I won't name it as that is not relevant - anyone can do this with some effort) provides this capability as part of their Control Panel. They also provide paid certificates with a few of the big issuers, as they have for many years, but for most small sites Let's Encrypt works very well and is totally free. The setup literally takes only a minute. The key is that you have to give the user an IP address or CNAME first so that they can point the domain. Once the domain is resolving to your server, you can get the Let's Encrypt certificate.
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 am trying to create my own certificate for a adobe air application, I created one already based on this link: http://help.adobe.com/en_US/AIR/1.5/devappshtml/WS5b3ccc516d4fbf351e63e3d118666ade46-7f74.html
But when I install my application the publisher field is still set with unknown, which is at the end what I am trying to do, I need to set the publisher with one specific value.
Thanks a lot!
You need to buy a code-signing certificate from a company like Verisign orThawte or another Certificate Authority.
Read this blog by Christian Cantrell for more info on how to get the certificates.
The pages where you can buy the certificate from Thawte and Verisign.
I don't think Thawte allows individuals to buy the certificate, but Verisign does.
Remember, you need to buy the Adobe AIR code signing certificate