I would like to know whether it is possible to change the signature algorithm from SHA1 to SHA256 in Websphere Application Server V7.0.0.17. ? If yes, is there any link which explains this.
Yes it's possible. If you procured your certificates from a CA other than the one built into WAS, procure new ones. If you let WAS manage your PKI, follow the instructions here:
http://www-01.ibm.com/support/docview.wss?uid=swg21959568
To convert these certificates with the Administrative console click
Security > SSL certificate and key management > Manage FIPS. Then
click Convert Certificates
Related
Is it possible to have Wazuh Manager served through custom SSL certificates? The wazuh-certs-tool gives you a self cert, and every other way to get it served through SSL has failed.
The closest I've gotten to getting this to work is I've had the dashboard being served by a custom SSL, I had agents connecting to it successfully and providing a heartbeat, but had zero log flows or events happening. When I had it in this state, I saw the API calls were coming from what appeared to be a Java instance, erroring out complaining about receiving certificate. I saw a keystore file located at /etc/wazuh-indexer. Do I also need to add the root-ca cert here as well?
It seems that your indexer's excepted certificates do not match the certificates in your manager or the dashboard.
If you follow the normal installation guide, it shows how and where to place your certificates, that are created using the wazuh-cert-tool. But, certificates can be created from any other source, as long as they have the expected information, you can check that informationenter link description here here.
I would recommend you follow the installation steps in the installation guide, from scratch to make sure you copy each excepted certificate in it's place and that the configuration files for your indexer, dashboard, and manager take into account the correct files. All you would need to change, the creation of the certificates, to have your own custom certs.
In case of further doubt, do not hesitate to ask.
I have a dsc token, im aware that they can be only signing, or they can be signing and encryption. How do i check?
KeyUsageFlag for X509 certificate is a bitwise flag.
Please refer: X509KeyUsageFlags Enum
There can be a single certificate with both the flag set (addation of values for DigitalSignature and KeyEncipherment) i.e. 128 + 32 or two different certificates. This depends on how Certifying Authority choses to issue the certificate.
How do i check?
Method 1: You must have Smartcard or USB Token driver installed which pushesh Certificates in token to Windows Certificate Store on inserting the token. Then run certmgr.msc to open Certificate Manager; go to Personal Certificates, double click the required certificate to open the Certificate Details and check Key Usage property in Details tab. Values displayed here are in Hex. like: Digital Signature (80)
Method 2:
You may filter on key values and check as above.
Install Signer.Digital Browser Extension as described here
Once Extension is installed and available in the browser, open any site so that browser loads extension script and execute below commands from the console of the browser
SignerDigital.getSelectedCertificate("", 32) - to list only Encryption Certificates
SignerDigital.getSelectedCertificate("", 128) - to list only DigitalSignature Certificates.
Here 32 and 128 are X509KeyUsageFilter values as discussed above.
What are the basic requirements for secure X.509 self-signed certificates intended for use as OpenId Connect token-signing and token-validation credentials?
I have an IdentityServer4 project, and I've been experimentally generating certificates with many different options and settings via Powershell's New-SelfSignedCertificate command. It seems almost any combination of options are accepted for token-signing and token-validation purposes.
Most of what I find online relates to code-signing, not token-signing, and I've found nothing about token-validation. It seemed like something I'd expect in the reference section of Identity Server's documentation, but they bounced my question as "not a bug," so here I am trying my luck with the general public.
Are there applicable standards, and how do they translate into New-SelfSignedCertificate parameters?
I found the following link which appears to be how Brock is creating his certificates.
https://brockallen.com/2015/06/01/makecert-and-creating-ssl-or-signing-certificates/
I'm using the SignedXml.CheckSignature(X509Certificate2, boolean) method. I would like to know what checks are performed when deciding the validity of the certificate. I have verified that the Current User/Not Trusted list is checked. The documentation says it will use the "address book" store, searching by subject key identifier, to build the certificate chain. I imagine this means the Local Machine and Current User certificate stores?
Am I right to think that certificate revocation and signature timestamp are not checked? To do an OCSP check for certificate revocation, am I obliged to use Bouncy Castle?
In the remarks in the msdn article you link to one finds:
In version 1.1 of the .NET Framework, the X.509 certificate is not verified.
In version 2.0 and later, the X.509 certificate is verified.
In version 2.0 and later of the .NET Framework, the CheckSignature method will search the "AddressBook" store for certificates suitable for the verification. For example, if the certificate is referenced by a Subject Key Identifier (SKI), the CheckSignature method will select certificates with this SKI and try them one after another until it can verify the certificate.
Thus, first of all the behavior of that method has changed in different .NET framework versions. So for reproducible results, you had better not count on that method even check the certificate at all.
Furthermore, the formulation try them one after another until it can verify the certificate sounds like there just might be the mathematical test whether or not the certificate is signed by its alleged issuer.
https://referencesource.microsoft.com/#System.Security/system/security/cryptography/xml/signedxml.cs,b9518cc2212419a2
It checks
The certificate has no Key Usage extension, or the Key Usage extension has either Digital Signature or Non Repudiation usages enabled
The certificate chains up to a trusted root authority
The certificate has not been revoked
The certificate was not expired when you called this method
It doesn't know when the document was signed, so it doesn't answer that question.
That none of the certificates in the chain are explicitly prohibited by the user or system configuration.
Currently our company uses a digital certificate from Versign/Symtanec for code signing our software.
We have someone in our company attempting to persuade us to use a self-signed certificate instead of one purchased from Verisign/Symantec. Partially as a "cost-down" procedure (even though they're pretty damn cheap for a 2-3 year renewal), and partially to make things easier in a patching sense, as the systems our software runs on (industrial machines) has installed software with a non-Windows certificate store in which our certificate also needs to be managed. Apparently they want use to use the Windows Root CA in order to generate our certificate so we don't have to keep patching new certificates on and our certificate will essentially last as long as the Windows Root CA is valid ...
Everywhere I've been looking, I've found that some people use self-signed certificates for things like website identity verification over the net, but when used in a code-signing context, there are a lot of examples for certificate generation and people saying that you can use them for testing in an environment that's closer to a production environment (which I have done in the past), but I can't find any hard reasons as to why not to use a self-signed certificate for code-signing production software.
It's been a while since I've had to look a the certificate side of things, but this just feels wrong.
It's possible that just I'm not experienced enough with certificates to see why this is a good idea. Does anyone have any input to help me understand the full implications of this?
Using a self-signed certificate should not work. The idea is that "someone trustable" (not you; but Verisign or some other party that should check your credentials) confirms that something is certified.
I'm not sure exactly how this works in Windows. Might be that they didn't implement something properly.
There is no problem using a self signed certificate in windows. Just put the root CA certificate and the signing cert in the Windows cert store of the client machines that will run the signed application and/or driver.
Managing self signed certs within an organization is a PITA. Hence why people pay good money to get somebody else to do it.
If you are going to distribute your signed code outside your organization it is even more painful as you will need to persuade your customers to accept your CA certificate, and nobody should ever accept a root certificate from an unknown source or sent via an insecure or unverifiable means.
See this answer for instructions on creating a self signed CA and signing certificates using it.
The same is possible (but in my opinion more complicated) using Windows PowerShell, The sequence is he same but the commands change.