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.
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 setup an API Connect developer portal in the sandbox catalog (I've been following the basic tutorials about configuring an API developer portal found here).
I receive a message saying that i'll get a one time login link so that i can login to the portal as admin and reset my password. However, this never arrives. I have tried configuring the portal a number of times now and this link never comes. Therefore i'm unable to login as admin.
I've also tried using the 'request new password' option on the developer portal itself and entering my email but this also does not work
Is there a way I can retrieve the login link?
This could be a number of things:
1) the IBM emails often get flagged as spam
2) the IBM email server, or rather the people they've contracted this out to, doesn't fully comply with DKIM/SPF security, so if you are on a corporate server that requires this then you won't get your emails.
The workaround I've done in the past is spin up a gmail account and be sure to check my spam folder.
A year ago I published a Visual Studio Code extension with vsce. I wish to publish an update, but lost the old token. I created a new one, but have not been able to find the right combination of permissions to republish.
Without supplying a new token, I get:
> vsce publish
ERROR Failed request: (401)
Using the new token with Full access scope on All accessible organizations or with the documented Marketplace scopes, I get:
> vsce publish -p newtoken
ERROR Access Denied: xxx needs the following permission(s) on the resource /aaa/bbb to perform this action: Make changes to, share, or view certificate of an existing extension
What have I missed in setting up permissions to republish?
Arg. I should have known once I took the time to post a question I'd figure out the problem. Back story: After adopting Azure AD, there was great confusion among developers here between Office 365 accounts and Microsoft accounts--because we had been advised to use the same email address for both.
Long story short, the problem was I was attempting to publish using a token from my Office 365 account, when the extension was originally published under my Microsoft account. It was long enough ago that I didn't remember that. I also gave my O365 account access to the organization owned by my Microsoft account, so I could conveniently access various resources with either one.
I created a new token under my Microsoft account, and boom, publish succeeded.
When I am Installing My Customized Word Add-in on Client Machine it is Giving this Warning "Unknow Publisher Install or Dont Install".
How do get I get rid of this warning?
The certificate you create (a temporary one) is only valid for your computer.
To get rid of "unknown publisher" you need to sign you addin with a code signing certificate purchased from a trusted authority. To buy one you'll need to contact that authority, and prove your identity.
Some list of code signing authorities can be found in this topic for example:
https://stackoverflow.com/questions/1077800/which-code-signing-authority-should-i-go-with
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.