I am following the directions here: https://learn.microsoft.com/en-us/azure/iot-edge/how-to-create-transparent-gateway.
When I create the certificates using OpenSSL and the 'New-CACertsEdgeDevice myGateway' commands, I end up with an Elliptical Curve based private key which fails when I configure the edge gateway with the message
"Currently RSA is only supported".
I modified the New-CACertsCertChain script in ca-certs.ps1 (set the $useEcc var to $false) and reran. The script succeeds, but now the New-CACertsEdgeDevice script fails with:
New-SelfSignedCertificate : Cannot convert 'System.Object[]' to the
type 'Microsoft.CertificateServices.Commands.Certificate' required by
parameter 'Signer'. Specified method is not supported.
Any idea what I am doing wrong?
I found an answer to this, although I am still not sure of the root cause.
These steps allowed me to create certificates that worked...
I kept the change I made to the New-CACertsCertChain (mentioned above)
I erased all the previous certs from the machine cert store
Then I closed the existing PowerShell console and started a new admin one.
I installed OpenSSL from here: https://sourceforge.net/projects/openssl/ # this directory: C:\utils\openssl\bin
I set up the environment paths as follows:
$ENV:PATH += ";C:\utils\openssl\bin"
$ENV:OPENSSL_CONF="C:\utils\openssl\bin\openssl.cnf"
After that I continued with the articles directions and it worked. I did get a warning about not finding C:/OpenSSL/openssl.cnf, but I ignored it.
I do not think you are doing anything wrong.
It appears that there is a problem with the powershell scripts. The good news is that there is a fix to the instructions at the Azure IoT C SDK GitHub branch CACertToolEdge which you can sync out and re-try.
I have filed an issue here: https://github.com/Azure/azure-iot-sdk-c/issues/337 to have this corrected.
Edit:
Jan 09 2018: It appears that the scripts have fixed and you shouldn't run into this specific problem.
Related
I was trying to follow this tutorial:
https://docs.opensea.io/docs/1-structuring-your-smart-contract
And even found this extremely helpful YouTube video to guide me:
https://www.youtube.com/watch?v=lbXcvRx0o3Y&ab_channel=DanViau
But I've encountered a problem after installing and setting up everything I needed. The problem occured when I tried to deploy the contracts using this bash command:
truffle deploy --network rinkeby
The error message I got is:
Error: There was a timeout while attempting to connect to the network.
Check to see that your provider is valid.
If you have a slow internet connection, try configuring a longer timeout in your Truffle config. Use the networks[networkName].networkCheckTimeout property to do this.
at Timeout._onTimeout (C:\Users\alonb\.nvm\versions\node\v12.22.5\bin\node_modules\truffle\build\webpack:\packages\provider\index.js:56:1)
at listOnTimeout (internal/timers.js:554:17)
at processTimers (internal/timers.js:497:7)
It's not caused by slow internet connection - I know that because I have tried executing this command on 3 different WiFi connections, one at 200 Mb/s rate.
I have tried to change the truffle-config.js file and add a longer timeout threshold (like suggested here), but the only thing that changed was that the error message took much longer to appear.
Technical info - I'm using Git Bash, npm version 6.14.14, nvm version 0.38.0, node version 12.22.5.
Any suggestions? I'm lost.
Alon
I also ran into this error when following the same tutorial.
I use Alchemy (not Infura), and the issue was my API_KEY.
In other tutorials I've followed, the scripts require the full alchemy API Key (ex. "https://eth-rinkeby.alchemyapi.io/v2/<random-key>").
So, when I was following this tutorial, that is what I supplied. And, I ran into the error you reported.
But when I reviewed the truffle.js script provided by the tutorial authors, I found this:
const rinkebyNodeUrl = isInfura
? "https://rinkeby.infura.io/v3/" + NODE_API_KEY
: "https://eth-rinkeby.alchemyapi.io/v2/" + NODE_API_KEY;
Thus, the script was producing:
rinkebyNodeUrl = https://eth-rinkeby.alchemyapi.io/v2/https://eth-rinkeby.alchemyapi.io/v2/<**random-key**>
...which is clearly wrong.
Thus, ensuring I set my API_KEY environment variable only to random-key and not https://eth-rinkeby.alchemyapi.io/v2/https://eth-rinkeby.alchemyapi.io/v2/<random-key>, my contract deployed successfully.
Also, make sure you have enough ETH in your wallet on the Rinkeby network. Faucets always seem to work for a little while then stop working, so do some Google searches to find one that is currently functional.
The solution is incredibly easy -
Instead of using just the relevant part of the Alchemy key:
40Oo3XScVabXXXX8sePUEp9tb90gXXXX
I used the whole URL:
https://eth-rinkeby.alchemyapi.io/v2/40Oo3XScVabXXXX8sePUEp9tb90gXXXX
I had the same experience but when using hardhat not truffle.My internet connection was ok,try switching from Git bash to terminal(CMD).Use a completely new terminal avoid Gitbash and powershell.
Remove the function wrapper from provider inside the network configuration.
ropsten_infura: {
provider: new HDWalletProvider({
mnemonic: {
phrase: mnemonic
},
providerOrUrl: `https://ropsten.infura.io/v3/${project_id}`,
addressIndex
}),
network_id: 3
}
The rinkbery network has been decommissioned. Use Goerli or Sepolia network. Update your truffle config add a section for goerli in networks. E.g
goerli: {
provider: () =>
new HDWalletProvider(
mnemonic,
`https://goerli.infura.io/v3/${INFURAKEY}`
),
network_id: 5, // goerli's id
gas: 4500000, //
gasPrice: 10000000000,
}
The run the command
truffle deploy --network goerli
I started using Swift package manager and when I add repository with https (https://github.com/Alamofire/Alamofire.git) address authentication always fails when I try to login with my github account
Xcode authentication fail
But if I'm using git#github.com:Alamofire/Alamofire.git it will get added successfully. I tried regenerating new key, deleted .ssh directory but nothing makes https work and I still get xcode authentication failed because no credentials were provided error. I could use locally ssh url but in CI I need one with https.
It was a problem with git config. In .gitconfig file it was set to
[url "git#github.com:"]
insteadOf = https://github.com/
After removing this section https worked correctly
EDIT: as mentioned in comments you can easily access your gitconfig in terminal with command: git config --global --edit
In my case with Xcode 11.3.1 I had the same problem and I solved changing de auth method to SSH from HTTPS in Github account preferences on Xcode.
Building off of two previous answers, I solved this by doing what Abrahanfer did, setting Clone using to SSH in Xcode Preferences -> Account.
Then I used the SSH url of the repo, for example: git#github.com:AppPear/SwiftUI-PullToRefresh.git
you can use ssh URLs instead of https, e.g. git#github.com:ORG_NAME/REPO_NAME.git
I double clicked the error message Error while fetching remote repository: git#github.com:ORG/REPO-NAME.git or the The server SSH fingerprint failed to verify
in Xcode's Report Navigator which then a popup appeared asking if I wanted to trust the host. After clicking that I was able to add the Swift Package using SSH.
Selecting HTTPS or SSH in the Xcode Preferences did not fix for me because Xcode seems to automatically handle SSH GitHub URLs in the SPM flow.
what worked for me was both #SimonasDaniliauskas answer and #Abrahanfer answer
Basically in the command line I had to run:
git config --global --unset-all url.git#github.com:.insteadof
And in Xcode I had to go to Xcode > Preferences and switch my GitHub to use SSH
Btw, if you don't have ssh setup, follow this medium post or these GitHub directions. If you need change your ssh keys follow this YouTube tutorial
If you are facing this and your .gitconfig has below, and you want to keep it!
[url "git#github.com:"]
insteadOf = https://github.com/
just add below two lines after above two lines in your .gitconfig
[url "https://github.com/apple"]
insteadOf = https://github.com/apple
Duplicate above two lines and replace /apple with any other /user or /org where you might want to download your packages from
Try removing it and adding it again. If that won't work, remove your GitHub account from Xcode. Usually, git via ssh works better. What CI are you using?
For me, it seems more like a red herring (maybe a fellow developer accidentally checked in this small change related to swift package in project setting). I went to project setting, removed it from under "Swift Packages". It seems okay after that.
I keep having this issue in Xcode 12.0.1 (12A7300).
My GitHub credentials seemed to not work, even though I applied all the suggestions above.
The way I fixed it (for now, at least) was to switch to SSH only authentication.
I managed to get HTTPS working fine with CI. The solution, with bitrise, is to use 'Authenticate host with netrc', then Xcode will find private HTTPS repos properly. I am sure other CI platforms (or your own) can setup the same solution.
Adding repo via source tree and checking out repo through Xcode use some other tool, then adding same repo via SPM. Try creating SSH key via rsa key algorithm instead of ed255189 key algorithm. SPM tool comfortably work with rsa.
Note: rsa key authentication is slower than ed25519 key authentication.
I followed the other anwsers here with no success. Eventually it turned out that the package was added to XCode with my username inside the https domain, like that:
https://yarden_k#bitbucket.org/private/package/path.git
so I had to adjust the accepted answer the same way (I added those lines to .gitconfig file):
[url "git#bitbucket.org:"]
insteadOf = https://yarden_k#bitbucket.org/
And viola! It finally worked. Was a real headache to figure this one out.
Me too facing this problem
Check your repo access is correct and you have proper access for PUSH the code
They only gave me READ access, After facing this issue I'll informed to respective person and get WRITE access
I tried to install Neos CMS local under Windows 10 with a Wamp Apache Server. After creating the project with a composer and registering the Vhosts, I tried to run neos.demo/setup. Then I get an 500 internal server error with the message "Specified path not found”, for more information, take a look at the screenshot.
I checked the solutions for the exception code 1355480641, but nothing can solve my problem.
Thanks for your recommendations!
do you have set Neos.Flow.core.phpBinaryPathAndFilename in Configuration/Settings.yaml to the correct php.exe binary path?
This is not an actual solution, this is more of an alternative.
I was having troubles installing neos on windows 10 as well (not the same as you though), a really nice solution that I would recommend as alternative to wamp is bitnami-neos.
I got the same error in the current version of Neos CMS (v4.1). The solution to the problem was for me:
Adjust Configuration/Settings.yaml with the php.exe path (which you already did)
Launch an administrator cmd
Go to the Neos CMS directory
Run flow flow:core:compile
Run flow flow:cache:warmup
Now I could access Neos with XAMPP.
All credit for this answer goes to the following post: https://discuss.neos.io/t/running-neos-flow-on-windows-10-success/2752
I've installed update 1 to our TFS 2015 and I'm forced to run the configuration wizard again, but I don't know which option is correct. I tried all of them but neither seems to work. Is there a tfsconfig command which allows me to do it via powershell?
Update: When trying to run the configuration wizard I receive the following error message
TF254043: The readiness checks could not start. For more information, see the following log file
Invalid URI: The hostname could not be parsed
at System.Uri.CreateThis(String uri, Boolean dontEscape, UriKind uriKind)
at System.Uri..ctor(String uriString)
at Microsoft.TeamFoundation.Admin.WebBindingInfo.AsUri()
at Microsoft.TeamFoundation.Admin.ApplicationTierPlan.GenerateConfigurationPlan(TargetEnvironment env, ActivityInputs inputs, ActivityContext context)
at Microsoft.TeamFoundation.Admin.Engine.AdminActivity.GeneratePlans()
at Microsoft.TeamFoundation.Admin.Console.Models.BaseWizardViewModel.StartVerification()
I've created a case with the microsoft support and they're working on it.
If I remember right, there should be an upgrade option in the config wizard which you should be choosing.
I've got the following answer from microsoft which can be found here
In TFS 2015 you had an SSL binding with host name set to *. This is a valid binding, but unfortunately TFS does not handle this value correctly.
To workaround the issue, you can replace
<_x003C_Host_x003E_k__BackingField>*
with
<_x003C_Host_x003E_k__BackingField>
In the C:\ProgramData\Microsoft\Team Foundation\Configuration\SavedSettings\ApplicationTier\ApplicationTierSettings.xml.
After changing the given config value the upgrade wizard ran through without any issues and I could manually set the SSL binding to *.
NOTE: If you want to see the behaviour of this demo app, just go to www.collaborativepowernowinternational.us. Here, select the testssl.PersonController, and you may create a person. Then go and edit the person, where the SSL channel is designated, which will give a redirect loop.
It seems like with Jetty 9 more configuration items went into the start.ini file, I have version 9.05.
In order to test the most basic SSL/https, I am uncommenting the following lines in start.ini:
#===========================================================
# SSL Context
# Create the keystore and trust store for use by
# HTTPS and SPDY
#-----------------------------------------------------------
jetty.keystore=etc/keystore
jetty.keystore.password=OBF:1vny1zlo1x8e1vnw1vn61x8g1zlu1vn4
jetty.keymanager.password=OBF:1u2u1wml1z7s1z7a1wnl1u2g
jetty.truststore=etc/keystore
jetty.truststore.password=OBF:1vny1zlo1x8e1vnw1vn61x8g1zlu1vn4
jetty.secure.port=8443
etc/jetty-ssl.xml
#===========================================================
# HTTPS Connector
# Must be used with jetty-ssl.xml
#-----------------------------------------------------------
jetty.https.port=8443
etc/jetty-https.xml
No other Jetty configuration changes. I then built the most basic Grails app (has a Person class) where I set certain controller actions to secure, which works fine on my development machine using an older built in Jetty version (that Grails includes). This is done simply by including spring-security-core and then adding the following lines to a configuration file:
grails.plugins.springsecurity.secureChannel.definition = [
'/person/list': 'REQUIRES_INSECURE_CHANNEL',
'/person/delete/**': 'REQUIRES_SECURE_CHANNEL',
'/person/edit/**': 'REQUIRES_SECURE_CHANNEL',
'/person/show': 'REQUIRES_INSECURE_CHANNEL'
]
grails.plugins.springsecurity.portMapper.httpPort=80
grails.plugins.springsecurity.portMapper.httpsPort=443
When I access the person/edit action I get a redirect loop in the browser (using deployed WAR file to Jetty 9 on dedicated CentOs 6 machine). This is using the provided keystore that comes with Jetty 9, just uncommenting the lines in start.ini to use it.
The main Jetty SSL configuration page I'm reading is here. What isn't clear to me is, is updating the start.ini file enough? If not, how exactly does one add the lines in jetty-https.xml described in this previous link, i.e. the lines:
<New id="sslContextFactory" class="org.eclipse.jetty.util.ssl.SslContextFactory">
<Set name="KeyStorePath"><Property name="jetty.home" default="." />/etc/keystore</Set>
<Set name="KeyStorePassword">OBF:1vny1zlo1x8e1vnw1vn61x8g1zlu1vn4</Set>
<Set name="KeyManagerPassword">OBF:1u2u1wml1z7s1z7a1wnl1u2g</Set>
<Set name="TrustStorePath"><Property name="jetty.home" default="." />/etc/keystore</Set>
<Set name="TrustStorePassword">OBF:1vny1zlo1x8e1vnw1vn61x8g1zlu1vn4</Set>
</New>
Not sure how to add them, but they also seem a duplicate of the start.ini file lines above.
Can you please help help me get the most basic Jetty SSL running? Thanks much.
If not familiar with Grails, one can simply download it, then create a domain class -- there is a command line option for this. Then give it fields String firstName, String lastName. Then there are commands to generate a controller and views for it -- this is all totally automatic. Then one adds the plugin, spring-security-core. In chapter 16/17 of this doc and as I have shown, when lists which controller actions are secure, such as person/edit.
You actually have enough here for just the Jetty portion of this to be working using the default trial keystore we ship in Jetty 9.0.6 distribution.
Simply the blurb you have above is enough to make SSL work within Jetty. I downloaded the 9.0.6 distribution and uncommented those lines and it works. Well, I had to go into the start.d/demo.ini file and remove the last two lines with etc/jetty-ssl.xml and etc/jetty-https.xml because they would get run twice...but I digress.
If you start up Jetty you can navigate to https://localhost:8443 and it will complain about being an untrusted certificate and then load up the jetty distribution page.
Based on that I would say this is likely some sort of grails configuration issue that I sadly don't know the answer too, sorry.
Starting Jetty 9.1, things have changed, and you have to follow the instructions in here for things to look correct, per Jetty developers. Moreover, you are not supposed to change/delete/edit anything in ${jetty.home}'s directories. Here's what you need to do for a self-signed certificate based SSL/HTTPS on Jetty 9.1+:
(a) set up your environment variable $JETTY_HOME to point to where you installed your jetty tar bundle, say /opt/jetty/.
(b) Create a new directory, /tmp/myJettyApp, point it to $JETTY_BASE in your environment.
(c) cd to $JETTY_BASE
(d) Follow instructions in here:
/home/sonny $ cd $JETTY_BASE
/tmp/myJettyApp/ $ java -jar $JETTY_HOME/start.jar --add-to-startd=https,http2
(e) Set your port if you'd like:
/home/sonny $ cd $JETTY_BASE;
/tmp/myJettyApp/ $ java -jar $JETTY_HOME/start.jar jetty.ssl.port=8444
(f) And now, run jetty:
/tmp/myJettyApp/ $ java -jar $JETTY_HOME/start.jar
you will see that HTTPS is running at port 8444. Now, if you want to make jetty listen in the traditional HTTPS port, you have to use sudo to run:
/tmp/myJettyApp/ $ java -jar $JETTY_HOME/start.jar jetty.ssl.port=443
/tmp/myJettyApp/ $ sudo java -jar $JETTY_HOME/start.jar
Note that this already does the self-signed certs etc. automagically.
Now, if you want to generate your own self-signed certificate (say, because you want to modify the validity to an arbitrary large or small value, depending on your needs), follow the instructions in here, generate a new self-signed cert using keytool and then place it in $JETTY_BASE/etc/ and modify the $JETTY_BASE/start.d/ssl.ini for jetty.sslContext.keyStorePassword and jetty.sslContext.keyManagerPassword respectively. BTW, for the last two ssl.ini passwords, you can use the obfuscated plain text password you used when you ran keytool or use the plain text ones. If you want to obfuscate them, run {jetty.home} $ java -cp lib/jetty-util-9.3.6.v20151106.jar org.eclipse.jetty.util.security.Password "MyInterestingAndAwesomePassword"
Hope this helps someone.