Running
netsh http add sslcert hostnameport=xxx:443 appid= 'XXX' certhash=XXX certstorename=MY clientcertnegotiation=enable
I get
The following command was not found: http add sslcert hostnameport=xxx:443 appid= 'XXX' certhash=XXX certstorename=MY clientcertnegotiation=enable
Seems that "http" doesn't exist in netsh of Windows 10 IoT Core.
Any workaround to solve it?
Windows IoT Core doest not support netsh http command. If you want to import the ssl certificate on Windows IoT Core. You can use following command:
Copy cert to C:\ on the device.
PS C:> Enter-PSSession -ComputerName -Credential Administrator
[]: PS C:\Data\Users\Administrator\Documents> cd C:\
[]: PS C:>Set-Location -Path cert:\LocalMachine\Root
[]: PS Cert:\LocalMachine\Root> Import-Certificate -Filepath C:***.pem, if your certificate file is pfx, you can use Import-PfxCertificate command instead.
In addition, you can also import the certificate using programming. More information please see here.
Related
I am using Saucelabs to test my application on Mac, chrome configuration as I am using windows machine.
As per Saucelabs documentation, downloaded the Saucelabs Connect Proxy. Extracted the file and went to bin folder in command line and executed the below command
bin/sc -u <sauce_username> -k <sauce_accesskey> -x <sauce_data_center> -i <tunnel_id>
I got the message on the command line as "Sauce Connect is up, you may start your tests." Showed one tunnel is active on the SauceLabs my account under tunnel tab.
I started the session by going to Live --> Crossbrowser; selected the tunnel, localhost application url, browser(chrome 90) and Mac-Sierra and Start Session
Opened the application but it didn't show the feature which are on localhost.
Anyone, please help me on this, is there anything wrong i am doing in the proxy connection, because the same is working fine, if i directly open the application url on my windows machine with chrome.
I found the answer in the sauce labs documentation itself. The problem i am getting is related to SSL and here the solution.
If you don't want any domains to be SSL re-encrypted, you can specify all with the argument (i.e., -B all or --no-ssl-bump-domains all)
Now when run the below command to start the tunnel it resolve the issue.
bin/sc -u <sauce_username> -k <sauce_accesskey> -x <sauce_data_center> -i <tunnel_id> -B all
I'm new in ASP.NET.
Environment:
Ubuntu 18.04
Visual Studio Code
.NET SDK 2.2.105
I'm in trouble with some command running.
I was reading tutorial at
https://learn.microsoft.com/ja-jp/aspnet/core/tutorials/razor-pages/razor-pages-start?view=aspnetcore-2.2&tabs=visual-studio-code
and ran this command:
dotnet dev-certs https --trust
I expect https://localhost should be trusted.
but I found the error message;
$ Specify --help for a list of available options and commands.
It seems that the command "dotnet dev-certs https" has no --trust options.
How to resolve this problem?
On Ubuntu the standard mechanism would be:
dotnet dev-certs https -v to generate a self-signed cert
convert the generated cert in ~/.dotnet/corefx/cryptography/x509stores/my from pfx to pem using openssl pkcs12 -in <certname>.pfx -nokeys -out localhost.crt -nodes
copy localhost.crt to /usr/local/share/ca-certificates
trust the certificate using sudo update-ca-certificates
verify if the cert is copied to /etc/ssl/certs/localhost.pem (extension changes)
verify if it's trusted using openssl verify localhost.crt
Unfortunately this does not work:
dotnet dev-certs https generates certificates that are affected by the issue described on https://github.com/openssl/openssl/issues/1418 and https://github.com/dotnet/aspnetcore/issues/7246:
$ openssl verify localhost.crt
CN = localhost
error 20 at 0 depth lookup: unable to get local issuer certificate
error localhost.crt: verification failed
due to that it's impossible to have a dotnet client trust the certificate
Workaround: (tested on Openssl 1.1.1c)
manually generate self-signed cert
trust this cert
force your application to use this cert
In detail:
manually generate self-signed cert:
create localhost.conf file with the following content:
[req]
default_bits = 2048
default_keyfile = localhost.key
distinguished_name = req_distinguished_name
req_extensions = req_ext
x509_extensions = v3_ca
[req_distinguished_name]
commonName = Common Name (e.g. server FQDN or YOUR name)
commonName_default = localhost
commonName_max = 64
[req_ext]
subjectAltName = #alt_names
[v3_ca]
subjectAltName = #alt_names
basicConstraints = critical, CA:false
keyUsage = keyCertSign, cRLSign, digitalSignature,keyEncipherment
[alt_names]
DNS.1 = localhost
DNS.2 = 127.0.0.1
generate cert using openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout localhost.key -out localhost.crt -config localhost.conf
convert cert to pfx using openssl pkcs12 -export -out localhost.pfx -inkey localhost.key -in localhost.crt
(optionally) verify cert using openssl verify -CAfile localhost.crt localhost.crt which should yield localhost.crt: OK
as it's not trusted yet using openssl verify localhost.crt should fail with
CN = localhost
error 18 at 0 depth lookup: self signed certificate
error localhost.crt: verification failed
trust this cert:
copy localhost.crt to /usr/local/share/ca-certificates
trust the certificate using sudo update-ca-certificates
verify if the cert is copied to /etc/ssl/certs/localhost.pem (extension changes)
verifying the cert without the CAfile option should work now
$ openssl verify localhost.crt
localhost.crt: OK
force your application to use this cert
update your appsettings.json with the following settings:
"Kestrel": {
"Certificates": {
"Default": {
"Path": "localhost.pfx",
"Password": ""
}
}
}
While the answer provided by #chrsvdb is helpful it does not solve all problems. I still had issue with service-to-service communication (HttpClient - PartialChain error) and also you must reconfigure Kestrel to use your own certificate. It is possible to create a self-signed certificate and import it to the .NET SDK. All you need is to specify the 1.3.6.1.4.1.311.84.1.1 extension in the certificate.
After that the cert can be imported into .NET Core SDK and trusted. Trusting in Linux is a bit hard as each application can have it's own certificate store. E.g. Chromium and Edge use nssdb which can be configured with certutil as described John Duffy. Unfortunately the location to the nssdb maybe different when you install application as snap. Then each application has its own database. E.g. for Chromium Snap the path will be $HOME/snap/chromium/current/.pki/nssdb, for Postman Snap the will be $HOME/snap/postman/current/.pki/nssdb and so on.
Therefor I have created a script which generates the cert, trusts it for Postman Snap, Chmromium Snap, current user nssdb and on system level. It also imports the script into the .NET SDK so it will be used by ASP.NET Core without changing the configuration. You can find more informations about the script in my blog post https://blog.wille-zone.de/post/aspnetcore-devcert-for-ubuntu
In adition to crisvdb answer, I've several information to add and is the continuation of the walktrough. I don't comment because is pretty complex comment this, but before this answer take a look to crisvdb answer first and then return to continue.
Take the "in detail" crisdb answer.
You can make your cert in any folder, can be or can't be in the same folder of the app.
Take openssl verify -CAfile localhost.crt localhost.crt as not optional step, mandatory. It will help.
Do not recompile or touch the code meanwhile you are doing this, in order to get first scenario clean.
If you run sudo update-ca-certificates that will answer you in wich folder the certified should be copied.
In some distributions, as Raspbian for Raspberry Pi, CA certificates are located in /etc/ssl/certs as well as /usr/share/ca-certificates/ and in some cases /usr/local/share/certificates.
Do not copy the cert manually to trusted certs, run sudo update-ca-certificates after you copy the cert in the right folder. If it doesn't work (doesn't update or add any certificate) copy it to every folder possible.
If you use a password while making the certificate, you should use it in the appsettings.json
If you get this error:
Interop+Crypto+OpenSslCryptographicException: error:2006D002:BIO
routines:BIO_new_file:system lib
Take in consideration that error means "access denied". It can be because you don't have permissions or related.
7b) Could be also that the file is not found, I use the entire path in the config:
"Path": "/home/user/www/myfolder1/myapp/localhost.pfx",
After that, and if everything works, you could see a 500 error if you are using Apache or Apache2.
If you get the following error in the apache logs of the site:
[ssl:error] [remote ::1:yourport] AH01961: SSL Proxy requested for
yoursite.com:443 but not enabled [Hint: SSLProxyEngine] [proxy:error]
AH00961: HTTPS: failed to enable ssl support for [::1]:yourport
(localhost)
you must set in the VirtualHost the following configuration after SSLEngine On and before your ProxyPass
SSLProxyEngine on
After that, and if everything works, you could see a 500 error if you are using Apache or Apache2.
If you get the following error in the apache logs of the site:
[proxy:error] [client x.x.x.x:port] AH00898: Error during SSL
Handshake with remote server returned by /
[proxy_http:error] [client x.x.x.x:port] AH01097: pass request body failed to [::1]:port
(localhost) from x.x.x.x()
you must set in the VirtualHost the following configuration after SSLProxyEngine on and before your ProxyPass
SSLProxyVerify none
SSLProxyCheckPeerCN off
SSLProxyCheckPeerName off
UPDATE
If you are renovating this, and using the same names, take in consideration that you should remove your pem file from etc/ssl/certs
UPDATE 2
If it returns:
Unhandled exception. Interop+Crypto+OpenSslCryptographicException: error:2006D002:BIO routines:BIO_new_file:system lib
Check that your pfx file is on 755 permissions.
If appsettings.json seems to be don't load (on port 5000 by default or SQL or any configuration doesn't load or can't be read), take in consideration that the dotnet must be executed on the same directory where is appsettings.json
Looks like this is a known issue with dotnet global tools and that specific command is only available for MacOS and Windows. See this issue on github: Issue 6066.
It seems like there may be a work around for Linux users based on this SO post: ASP.Net Core application service only listening to Port 5000 on Ubuntu.
For Chrome:
Click "Not Secure" in address bar.
Click Certificate.
Click Details.
Click Export.
Run: certutil -d sql:$HOME/.pki/nssdb -A -t "P,," -n {FILE_NAME} -i {FILE_NAME}
Restart Chrome.
It looks like the following could help to trust the dotnet dev certs:
https://blog.wille-zone.de/post/aspnetcore-devcert-for-ubuntu/
Then you will see also in the browser that certificate is OK and valid for the next yeat.
Give it a try...
Good luck!
We were using an older version of Jboss 4.x with JDK 5 on CentOS 5.x, this version of Jboss is very old now, even this version is also not supported by RedHat now.
Now we are upgrading to jboss-eap 6.2 and jdk1.7.0_60 and CentOS 6.x in UAT and AWS Linux1 AMI for Production, I have installed Jboss 6.2 in /var/lib/jboss-eap-6.2 folder. Necessary modification in the code are already done, application is working fine and Jboss is running as a process using below command.
./standalone.sh -c standalone-full.xml -b 0.0.0.0 -bmanagement 0.0.0.0
Below command shows that process is running on port 8080.
netstat -aptn | grep LISTEN
Please help configure Jboss 6.2 as a service and set Auto-start, when OS starts?
Follow the below steps to Configure Jboss6.2 as Service and configure it as Auto restart. The process is same for CentOS 6.x and AWS Linux1 AMI.
Copy files into system directories
a. Copy the modified configuration file to the /etc/jboss-as directory.
mkdir /etc/jboss-as
cp /var/lib/jboss-eap-6.2/bin/init.d/jboss-as.conf /etc/jboss-as/
Uncomment following line
JBOSS_USER=root
and add the following line at the end of this file.
export JBOSS_USER
b. Copy the start-up script to the /etc/init.d directory.
cp /var/lib/jboss-eap-6.2/bin/init.d/jboss-as-standalone.sh /etc/init.d/jboss-62
Do following changes in /etc/init.d/jboss-62 file
i)-Set Java Home JAVA_HOME=/usr/java/jdk1.7.0_60 export JAVA_HOME
ii)-Set JBOSS Home JBOSS_HOME=/var/lib/jboss-eap-6.2 export JBOSS_HOME
iii)-Change Configuration xml file name(you may give what ever configuration file name you are using)
JBOSS_CONFIG=standalone-full.xml
iv)-Add "-b 0.0.0.0 -bmanagement 0.0.0.0" in the following line, so that binding is set for every IP address on this system
daemon --user $JBOSS_USER LAUNCH_JBOSS_IN_BACKGROUND=1
JBOSS_PIDFILE=$JBOSS_PIDFILE $JBOSS_SCRIPT -b 0.0.0.0 -bmanagement
0.0.0.0 -c $JBOSS_CONFIG 2>&1 > $JBOSS_CONSOLE_LOG &
Add the start-up script as a service.
Add the new jboss-as-standalone.sh ( i.e jboss-62 ) service to list of automatically started services, using the chkconfig command.
chkconfig --add jboss-62
Start the service.
service jboss-62 start
Make the service to start automatically when you restart your
server.
chkconfig jboss-62 on
Restart the service
service jboss-62 restart
Now Jboss6.2 configuration as a Service as Auto restart is complete.
Reboot os and check that service is running. Run below command ot verify that service is running on port 8080
netstat -aptn | grep LISTEN | grep 8080
I created Kaa sandbox instance on the AWS Linux host. I am getting some of the issues
Still I am not able to see the management button on the kaa Sandbox console.
I am not able to connect AWS with using ssh. I followed all the required step to connect to AWS Linux host, but not lucky to connect.
My problem is that, I would like to change the host IP in the sandbox setting with my AWS linux host IP, so that my end point device gets connected to host,
Still I am struggling with above points. Please advise.
Regards,
Prasad
That seems to be an issue with the Kaa 0.10.0 Sandbox for AWS. We created a bug for tracking this.
For now, you can use the next workaround:
echo "sudo sed -Ei 's/(gui_change_host_enabled=).*$/\1true/'" \
"/usr/lib/kaa-sandbox/conf/sandbox-server.properties;" \
"sudo service kaa-sandbox restart" | \
ssh -i <your-private-aws-instance-key.pem> ubuntu#<your-aws-instance-host>
Note: this is a multi-line single command that works correctly in bash (should also work in sh and others, but that is not tested).
Note 2: don't forget to replace
<your-private-aws-instance-key.pem>
<your-aws-instance-host>
with the respective key name and host name/IP address.
I am trying to setup ngrok on my homestead, but it is not opening my project.
I have run ngrok http 80 and copied the address in forwarding part of the output to my Homestead.yaml file to map it to my project, and ran vagrant provision after that:
Forwarding http://92832de0.ngrok.io -> localhost:80
Forwarding https://92832de0.ngrok.io -> localhost:80
But when I open the http://92832de0.ngrok.io in the browser it opens up ngrok page "It works" and not my project.
When I have changed the port to ngrok http 8000 then I get Laravel error message:
Whoops, looks like something went wrong.
You can use any of your application which is in homestead.
For that, you need to run the below command by replacing 'your-site.app:8000'
ngrok http -host-header=rewrite your-site.app:8000
Before that, you need to register into ngrok and install ngrok then use the authtoken that given in your account.
For more details, refer this https://ngrok.com/docs
This is how It worked for me:
1) I have downloaded the ngrok (https://ngrok.com/) on my Windows host machine and executed ngrok.exe.
It has opened a command line interface for me
2) I typed the following
ngrok.exe http 192.168.10.10 -host-header=homestead.test
And it gave me the link of where to go:
Forwarding http://123456.ngrok.io -> http://192.168.10.10:80
Forwarding https://123456.ngrok.io -> http://192.168.10.10:80
I just went there ans saw my local environment Laravel Project.
You can add a function like this to your ~/.profile or ~/.bash_profile script on the host machine:
rock(){
ngrok http 192.168.10.10:80 -host-header=$1
}
After that you can use it to proxify any site on your Homestead machine like this:
rock your-site.app:8000
If you have multiple sites on your homestead you have to:
ssh into your homestead.
run this command: share yoursite.test
and that's it.
In homestead ngrok is already installed by default,
You just need to create an account from ngrok at https://dashboard.ngrok.com/signup
And then run:
vagrant up (in folder Homestead)
vagrant ssh
cd to/your/project/proyect
ngrok authtoken your__ngrok__account___token
share yourproject.test