I transfer authority of Candy Machine to a new wallet address using this command line
ts-node ~/metaplex/js/packages/cli/src/candy-machine-v2-cli.ts update_candy_machine \
-e devnet \
-k ~/.config/solana/devnet.json \
-cp config.json \
-c temp \
--new-authority BwoAzDMxFVrG7tSdcBzy1H4yUcVX2FaDUFkCFVWMBbAL
But after transfer authority the mint stopped
Program logged: "Instruction: SetCollectionDuringMint"
Program invoked: Token Metadata Program
Program logged: "Instruction: Set and Verify Collection"
Program logged: "Update Authority given does not match"
Program consumed: 7483 of 1040268 compute units
Program returned error: "custom program error: 0x7"
Program consumed: 34700 of 1067485 compute units
Program returned error: "custom program error: 0x7"
I try to get back authority and the mint work again
https://explorer.solana.com/address/7ARq1Nxca8hfvzAnBsM7kq2tHWtHT6uE4teAVJPp3LtJ?cluster=devnet
This is happening because in order to set the collection during mint, the CandyMachine Authority and the collection NFT authority must match. When you create a Candy Machine all the NFTs will use as authority the pubkey of the wallet who create the CandyMachine, when you create the collection (using the webpage or just using the default one that is created during upload) the authority of this collection is the same pubkey that you used to create the Candy Machine.
So when you update the authority of the Candy Machine, the newly minted NFTs from this Candy Machine will have this new authority pubkey, but will still use the same collection that has the old authority pubkey, so when you try to set the collection to this new NFT it will find that NFT authority and collection authority does not match and will throw the error.
How to fix? you can just update the authority of the collection NFT (and all the old NFTs too) using metaboss, in order that ur collection authority match the new authority on the CandyMachine
Related
Toolkit to generate keystore and truststore with "-c 'hhh'",but the CN is 'localhost'?Can u get me suggestion?Thanks in advance!
-c,--certificateAuthorityHostname Hostname of NiFi Certificate Authority (default: localhost)
If you're running the TLS Toolkit in standalone mode, and this is not the first invocation, you likely already have a nifi-cert.pem and nifi-key.key file in the working directory. These files are the CA public certificate and private key respectively. They will be reused to continue signing newly generated node certificates because this allows for trust across the different nodes of the cluster (which is the intended use case for the toolkit).
If you want to create a new CA certificate and use that to sign the node certificates, you have a few options:
Copy the toolkit build directory to a new location and invoke it there. Ensure that the nifi-cert.pem and nifi-key.key files are not present. On the first invocation, a new CA certificate and key will be generated, with the specified certificate authority hostname.
Delete the nifi-cert.pem and nifi-key.key files from your existing toolkit build directory. Warning: You will no longer be able to sign certificates with the same CA key. For example, if you generated node1 and node2 certificates signed by CA_1, then delete CA_1 and want to add node3, you will not be able to sign node3 with CA_1. You will have to import multiple public CA certificates (CA_1 and the new CA_2, for example) into each node's truststore to allow for cross-trust.
Try to add -D in your command, to specify the CN and so on:
sudo bash tls-toolkit.sh client -c #YOUR_CA_HOST_FQDN -t #YOUR_CA_KEY_IF_ANY -p #CA_SERVER_PORT_IF_ANY -D "CN=#WHAT_EVER_YOU_WANT, OU=NIFI" -T PKCS12
I experienced the same problem here, my solution was to remove de target file, as suggested in previous post, and run the script with an additional param, in your case it should be something like this
tls-toolkit.sh standalone .... --certificateAuthorityHostname hhh
It worked for me
I have a p12 file, 'test.p12,' that has a certificate, the CA cert (self-signed), and private key for the certificate. The p12 file is generated using the BouncyCastle's C# API.
When trying to import the certificate by using 'CertUtil', i.e., 'CertUtil -f -p password -importpfx test.p12,' CertUtil generates the following error:
CertUtil: -importPFX command FAILED: 0x80090016 (-2146893802 NTE_BAD_KEYSET)
CertUtil: Keyset does not exist
Any clues as to what may be wrong? (I'm using Windows 10)
Using openssl, I can see that 'test.p12' does include the certificate, CA cert, and private key. The certificate is using an EC keypair, but I doubt that's a problem since I have a reference p12 file that uses the same algorithm and is imported by CertUtil without problem. Unfortunately, I have no detail on how the reference file is generated.
In my google searches, many seem to suggest that this may be a permission problem, but I doubt that's the case as I'm running the CertUtil as the Administrator.
When importing the same file using 'MMC' with the certificate snap-ins, the certificate is "successfully" imported if I force the MMC to store it in a specific store, e.g., Personal; otherwise, it prompts to select a Smart Card for the certificate. Could this be a related problem?
Thanks,
--Hyong
I got access denied when trying to do a certutil -backupKey. I already have Domain Admin and access to the CA cert (Read, Issue/Manage Certificates, Manage CA, Request Certificates). What Am I missing? I need to export the backup with the private key.
> Certutil: -backupKey command FAILED: 0x8007005 <WIN32:5> Certutil:
> Access is denied
You'll need to use an account with Enterprise admin. Domain admin is not enough (as I just spent 3 hours figuring out...)
I have an .p12 keystore file issued by the provider of a webservice that I'd like to communicate with (SOAP) through a PL/SQL procedure from an Oracle 11g2 database.
A wallet was created with:
$ orapki wallet create –wallet [walletdirectory] -pwd [password] -auto_login
And the resulting 'ewallet.p12'-file was subsequently replaced with the (renamed to 'ewallet.p12') keystore file.
However, the SOAP-requests cannot be authorised. The log of the service provider shows (full log not available to me):
Error log Apache httpd
[<timestamp>] [error] [client <IP>] access to <URL> failed, reason: SSL requirement expression not fulfilled (see SSL logfile for more details)
ACL-settings have been thoroughly audited. I am now exploring the possibility that the Oracle Wallet has not been set up properly (because perhaps simply replacing the keystore files is not possible). I cannot extract the private key from the supplied .p12 to add to the newly generated 'ewallet.p12'.
Thus I would like to use the Oracle Wallet Manager to create the Wallet. Some problems I've encountered.
I can not open the supplied .p12 file as a wallet in OWM
Renaming the supplied keystore to 'ewallet.p12' allows me to open the wallet in OWM, but upon entering the keystore password, displays "incorrect password"
Condensed question is: How do I create an Oracle Wallet from an already existing PKCS#12 file? Either as a complete product or by generating the required .SSO-file? Any other advice as to what might be the cause of this problem?
Note: using SOAPUI, I'am able to successfully communicate with the webservice using the supplied keystore.
The webservice was unable to be authorized because the cwallet.sso file was not correct in the Oracle Wallet. The complete procedure to generate a correct Oracle Wallet from an existing PKCS#12 Keystore is:
$ orapki wallet create -wallet /path/to/wallet -auto_login
Where the [path/to/wallet] targets an existing directory that already includes the PKCS#12 Keystore. This generates the correct cwallet.sso file. The certificates included in the keystore can now be shown with:
$ orapki wallet display -wallet /path/to/wallet
And the Oracle Wallet can now be associated with an ACL:
SQLPlus: EXEC DBMS_NETWORK_ACL_ADMIN.ASSIGN_WALLET_ACL('[acl_file.xml]','file:/path/to/wallet');
However, for reasons unknown to me, an Oracle Wallet created in this fashion cannot be opened using the Oracle Wallet Manager tool.
I have a c# program and part of it creates a self-signed certificate.
The problem is when i try to import the certificate in MMC it says "This certificate has an invalid digital signature."
And when i try to add this certificate through command prompt using netsh http add it says:
SSL Certificate add failed, Error: 1312 A specified logon session does not exist. It may already have been terminated.
I've tried all suggestions from other questions similar to this but to no luck.
I've also tried downloading Hotfix from Microsoft but it didnt work.
By the way, my machine is running in Windows7-64bit.
I ran into an answer here The basic issue is that DC authority cert creators get sloppy and create multiple certs for the same DC cert authority. I had my self-signed cert created using latest and grates DC cert authority certificate. I had to export and install both root cert and a self signed cert on my destination machine for it to recognize self signed cert used on the server. But the root cert I exported was a cert with the same name but different dates. Once I located the proper root cert and installed it on my destination computer everything worked flawlessly.
In my case it was due to an old self signed certificate with a small key length.
I found the solution here - https://security.stackexchange.com/a/82606/26742 to reduce the security (only in my dev environment)
certutil -setreg chain\minRSAPubKeyBitLength 512