I have created a trusted certificate as follows (cleaning up potential pre-junk). During that, I got the popups telling my that a gang of crazy donkeys can do evil things if this is a root cert. The last comamnd confirms that I have a working certificate. I even ran the commands twice to verify that cleaning would produce a warning too, which it did, just as expected.
dotnet dev-certs https --clean
dotnet dev-certs https --trust
dotnet dev-certs https --verbose
I haven't imported any PFX-files as my understanding is that working in development towards a localhost instance doesn't require that. That seems to be confirmed by the information in the console letting my know that the certificate is generated properly. Running dotnet dev-certs http --check produces no warnings (no confirmation neither, it's no content in the result).
The HTTPS developer certificate was generated successfully.
A valid HTTPS certificate is already present.
Then I executed a call to my token dispencer endpoint getting a reply as expected too. It comes back from a secure HTTPS on localhost:5001/connect/token and containes all the vital parts.
{
"access_token": "eyJhbGciO...Ow7EEkA",
"expires_in": 3600,
"token_type": "Bearer",
"scope": "myapi.read"
}
What bothers me is the warning with red icon and the text Unable to verify the first certificate.
I've made sure to disable SSL checking and turned off CA Certificated (althoug I haven't added any Client Certificates in that menu. Googling gives me a bunch of hits on problems related to Ubuntu and/or MacOs but I'm based on a good old Win10 so those turned out irrelevant.
Have I misunderstood the approach all together or, possibly, confused some of the concepts? If not, what can I do to trouble-shoot it further?
I dig in to this a little.
dotnet dev-certs https --trust command just creates/makes sure a new localhost certificate (with friend name ASP.NET Core HTTPS development certificate) and puts it into the trust root store.
IIS Express server however won't use it automatically. It still uses the certificate (friend name is localhost) that is created when you run the APS.NET Core web app for the first time. If this certificate is removed from trust root store you will get the cert error.
You have a few options to address this issue.
Reset the IIS Express cert.
Switch the cert IISExpress use to the one you just created, you can retrieve it using the PowerShell command below and following this link.
Get-ChildItem -path cert:\currentUser\My | Select-Object FriendlyName, subject, Thumbprint
Related
I am trying to create a GitHub action that runs on a windows server self-hosted runner and I'm stuck on my checkout failing at the LFS download portion
I'm using
- uses: actions/checkout#v3
with:
lfs: true
The checkout for the normal code works fine, but when it gets to the LFS download step I get a lot of messages complaining about x509: certificate signed by unknown authority.
LFS: Get "https://github-cloud.githubusercontent.com/alambic/details_changed_to_protect_the_innocent": x509: certificate signed by unknown authority
The self-hosted runner is on a domain that is behind a firewall that interrogates https traffic and inserts its own certificate into the chain, so I'm guessing that the unknown authority is that certificate, but I don't know where that certificate needs to be trusted so that things work.
The certificate is trusted by the OS and is installed in the certificate store through a group policy, but it seems that git LFS is verifying the certificate chain separate from that and complains anyway because the certificate is unexpected.
A common solution I've seen floating around for things like this is just turn off SSL checking, but that feels like just a temporary hack and not a real solution. I would like for this to work with all security in place.
As an additional note, this is running on a server that is also running TeamCity, and the TeamCity GitHub config is able to clone repos with LFS from that same server, so these problems are just inside of the GitHub action runner environment that gets set up.
Since the firewall only inserts its certificate into https traffic, I was able to get things working using an ssh-key. I added the private key as a secret and the public key to the repo's deploy keys, and now everything is working as expected.
- uses: actions/checkout#v3
with:
lfs: true
ssh-key: ${{secrets.repo_ssh}}
I can not use HTTPS with my web api so I tried running this command:
dotnet dev-certs https --trust
But I got this error :
Trusting the HTTPS development certificate was requested. A confirmation prompt will be displayed if the certificate was not previously trusted. Click yes on the prompt to trust the certificate.
There was an error trusting HTTPS developer certificate.
I also tried to clean and create a new one
dotnet dev-certs https -v
The HTTPS developer certificate was generated successfully.
But still facing the same issue.
I can not see localhost certificate in CurrentUser\Personal\Certificates
Sometimes this happens if you have multiple Certificates.
Execute certmgr.msc in Run
Clear all localhost certificates
On the commandline execute dotnet dev-certs https -t
You can check the certificate with dotnet dev-certs https --check. if this command returned nothing, every thing is OK.
run your application using dotnet run
I am unable to generate a valid dev localhost certificate for .NET Core.
When I run the dotnet dev-certs https -c -v command, I get the result No valid certificate found. When I subsequently run dotnet dev-certs https -v I get the message A valid HTTPS certificate is already present.
These messages seem to be conflicting. When I try to run a project using the localhost dev cert, I get the [expected] error:
System.InvalidOperationException: Unable to configure HTTPS endpoint. No server certificate was specified, and the default developer certificate could not be found.
To generate a developer certificate run 'dotnet dev-certs https'. To trust the certificate (Windows and macOS only) run 'dotnet dev-certs https --trust'.
Also, as an addition validation that things don’t seem to be working right, when I check my Keychain after running dotnet dev-certs https & dotnet dev-certs https --trust, no certificate is generated and/or placed in the Keychain.
Any thoughts on the cause of this? It seems from the command outputs that the CLI is writing to one location (unknown) where it thinks it already exists, but trying to read from another (active Keychain) where it is unable to find it.
I ended up recreating my macOS keychain and the issue was resolved.
I went to tools> nuget package manager > package manager console
copy pasted 'dotnet dev-certs https' and pressed enter. it worked fine thereafter
On Debian, using GitLab, I ran into issues with my self-signed certificate.
Reading through the code after a lot of searching on the Internet (I guess, it's the last resort, FOSS is helpful), I found the following lines in gitlab-shell/lib/gitlab_net.rb which left me... perplexed.
if config.http_settings['self_signed_cert']
http.verify_mode = OpenSSL::SSL::VERIFY_NONE
end
Most Stack Overflow responses about the diverse issues I've had until now have led me to believe that VERIFY_NONE, as you'd expect, doesn't verify anything. VERIFY_PEER seems, based on my reading, to be the correct setting for self-signed.
As I read it, it feels like taking steps to secure my connection using a certificate, and then just deciding to not use it? Is it a bug, or am I misreading the source?
gitlab-shell (on the GitLab server) has to communicate to the GitLab instance through an HTTPS or SSH URL API.
If it is a self-signed certificate, it doesn't want any error/warning when trying to access those GitLab URLs, hence the SSL::VERIFY_NONE.
But, that same certificate is also used by clients (outside of the GitLab server), using those same GitLab HTTPS URLs from their browser.
For them, the self-signed certificate is useful, provided they install it in their browser keystore.
For those transactions (clients to GitLab), the certificate will be "verified".
The OP Kheldar point's out in Mislav's post:
OpenSSL expects to find each certificate in a file named by the certificate subject’s hashed name, plus a number extension that starts with 0.
That means you can’t just drop My_Awesome_CA_Cert.pem in the directory and expect it to be picked up automatically.
However, OpenSSL ships with a utility called c_rehash which you can invoke on a directory to have all certificates indexed with appropriately named symlinks.
(See for instance OpenSSL Verify location)
cd /some/where/certs
c_rehash .
I just want to say that this is not normally something I do, but I have been tasked with it recently...
I have followed the heroku documentation for setting up SSL closely, but I am still encountering a problem.
I have added my cert to heroku using the following command:
heroku certs:add path_to_crt path_to_key
This part seems to work. I receive a message saying:
Adding SSL Endpoint to my_app ... done
I have also setup a CNAME for my hosting service to point to the endpoint associated with the cert command above. However, when I browse to the site I still receive a SSL error. It says my certificate isn't trusted and points to the *.heroku.com license, not the one I have just uploaded.
I have noticed that when I execute the following command:
heroku ssl
I receive the following:
my_domain_name has no certificate
My assumption is that there should be a certificate associated with this domain at this point.
Any ideas?
Edit: It appears that I did not wait long enough for the certificate stuff to trickle through the internets... however, my question regarding the "heroku ssl" command still puzzles me.
The Heroku ssl command is for legacy certificates:
$ heroku ssl -h
Usage: heroku ssl
list legacy certificates for an app
The command you need is heroku certs which will output the relevant certificate info for that project.