I have completed the docu-sign certification process and my integrator key in now certified.I have change my url from https://demo.docusign.net to https://docusign.net, which i am using for account authentication.
But still i am redircted to demo.docusign.net for signing process, what other changes need to be done after certification process and before go to production.
kindly guide me for the same.
The post certification guide can be found here
Your production URL should also be https://{server}.docusign.net/
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.
My workplace is looking to add the software developer role to our company's relationship with the IRS. I pulled down the latest PDF's from the IRS AIR site and it pointed me at two certificate authorities to have a certificate issued to us. On the IdenTrust website, IdenTrust says that as of last month they are no longer issuing the ACES certificates.
My question is, has anyone gotten a confirmation if we are to be using the IGC certificate?
I have verified that I have the latest versions of the PDF's.
Update:
We just got an email confirming the information that Das gave. Additionally, the IRS sent us a response to an inquiry we made regarding the certificates, confirming the use of the IGC certificates. They included information that they have updated the Publication 5258 on their site. I've checked the new revision of the publication and it does list the IdenTrust IGC certificate as one of two possibilities.
Thank you for your help.
Here is the response I got from the IRS when asking about this specific issue back on August 24th.
IGC certificates have been approved by the General Services Administration (GSA) to replace discontinued ACES certificates. We are in the process of updating our publication with this information.
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.
Good morning fellas !!
I have a question regarding WS-FEDERATION.
We have a partner (IDP initiated and SP Hosted) that is configured with WS-FEDERATION.
They use ADFS and we use OPENAM (we are the SP)
Everything is set up fine and running smoothly.
But their certificate is going to expire soon and we have to update it.
So from what I saw here what we are suppose to do :
Export the SP and IDP metadata , replace the X509 Certificate value with the new one then import those configuration back.
Is that correct ?
I am using OPENAM, and they have the ssoadm command mapped with a GUI.
So I exported both of those metadata, I replaced the certificate value and we will re-import them with the partner at the same time.
I never did that change, and I want to make sure that it is the proper way and that I am not missing anything !
Thank you for the help :) :)
In this situation you will find that ADFS has interim phases i.e.
Old certificate
Old and new
New
During the middle phase, you need to get the ADFS metadata and re-import into OpenAM.
That way there will be no down time as both certificates are catered for.
If you wait until the third phase, there will be some downtime until you have done the new import.
We're just going live with the Intuit API feature on our live application. We finished the last step of the process by uploading the X.509 certificate signed by Comodo PositiveSSL CA. Though our production access status shows up as ready now, we are having a problem using the production OAUTH credentials. We get an unauthorized exception using these credentials. The development OAUTH credentials work fine though. We also tried using Thawte SSL 123 but no luck even with that.
Also, the actual expiry date of the X.509 certificate, we uploaded is 16-Mar-2014 but when we upload this to the Intuit settings page, it shows expired (0/1/1). Please advice.
Adding the update here to this question- issue was with pointing to the wrong PFX file.