I have a self-hosted WCF service being tested now in QA using self-signed (makecert.exe) certificates for SSL. If the web service is started using admin rights and a .BAT file, the program has no trouble starting the SSL endpoint.
But if I start the web service as a normal windows service, running as "NT Authority\System", the program will frequently (but no always?!) fail to start, throwing an error that "may not have a private key that is capable of key exchange or the process may not have access rights for the private key"
This is the makecert command I used:
makecert -iv Cas_temp_Authority.pvk -n "CN=ServerName" ServerName.cer -sv
ServerName.pvk -ic ServerName.cer -sr localmachine -ss my -sky exchange -pe -eku
1.3.6.1.5.5.7.3.1
I used this netshell command to assign the certificate to the port
netsh http add sslcert ipport=0.0.0.0:8086 certhash=755f7fcf49ff3f06d9d7e551a10ef35776f2dc57
appid={42e1d4bf-7106-4666-90f7-4634456fb7f1} clientcertnegotiation=enable
I used this netshell command to set the port permissions:
netsh http add urlacl url=https://+:8086/ServiceName/MethodName/
user="NT Authority\System"
I know there is nothing wrong with the certificates or the programming code; if there was something wrong, the service would not start at all. The issue here is that it starts only as administrator using an .EXE and it will not start as a normal windows service.
I'd be grateful for any help.
have you tried using the winhttpcertcfg tool from microsoft?
winhttpcertcfg -g -c LOCAL_MACHINE\MY -s [cert common name] -a "NT Authority\System"
Related
In this article mosquitto_sub with TLS enabled I understand that you need to provide a capath or cafile option to mosquitto_sub (and pub) but I am having trouble figuring out where those files/paths come from.
Back in October I was able to run mosquitto_sub -h mymosquitto.com -p 8883 -v -t 'jim/#' -u <u> -P <pw> --capath ssl/certs from my desktop computer (running Mint 19). That no longer works. I did an apt install ca-certificates and found the .crt files in /usr/share/ca-certificates/mozilla/ but when I used that path, it still gave me: Error: A TLS error occurred.
This is a Ubuntu 18.04 server running Let'sencrypt. I tried to point the --cafile to the chain.pem file which came from:
allow_anonymous false
password_file /etc/mosquitto/pwfile
listener 1883
listener 8883
certfile /etc/letsencrypt/live/mymosquitto.com/cert.pem
cafile /etc/letsencrypt/live/mymosquitto.com/chain.pem
keyfile /etc/letsencrypt/live/mymosquitto.com/privkey.pem
But that didn't work either. Can someone please help me understand what I should be doing?
From the mosquitto_sub man page:
--capath
Define the path to a directory containing PEM encoded CA certificates that are trusted. Used to enable SSL communication.
For --capath to work correctly, the certificate files must have ".crt" as the file ending and you must run "openssl rehash [path to
capath]" each time you add/remove a certificate.
If you want to use a directory of certs you will have to make sure the openssl rehash command mentioned has been run on that directory.
If you want use a file from the letsencrypt --cafile with the fullchain.pem file
I have rethought my situation. Since my certs get regenerated every 3 months or so I'm going to have to redo my apps using the new files so I decided to just go back to rolling my own. I did that using this site: http://www.steves-internet-guide.com/mosquitto-tls/ and I'm back to where I was in October.Thanks to hardillb for the advise.
Jim.
I have a safari web-page connecting to secured web socket server (written with C# netcore 3.0).
I add server sertificate to trusted running this command (the same certificate I put on my websocket end point).
security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain certificate.crt
Everything seems valid (I have a blue cross near my certificate in Keys application)
but when I connect from safari (catalina os, mojave os) I get an error
OSStatus Error -9807. Invalid certificate chain
Also when I import certificate manually via Keys Application GUI there is no error. Everything works.
Can anyone explain is there any difference between "security add-trusted-cert" import and GUI manual import?
Maybe my add-trusted-cert command is wrong and I need some additional params?
This syntax works perfectly for me on MacOS Catalina, however, it must be run with elevated privileges (sudo or whatever).
sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain <MY_CERTIFICATE_FILE.pem>
Is it possible to programmatically installing LetsEncrypt Certificate on shared server, by using some opensource tool or PHP. Currently I'm generating Certificate on windows machine with "letsencrypt-win-simple" tool with W option which uses webdav to authenticate server. Certificate are generated locally in my windows machine and I've to configure it manually through cpanel every month.
Is it any possible automation for this process on certificate installation?
You can use Cpanel's API to install the new certificate. Here is a Linux example, but curl exists for Windows as well. You would need to change the paths in this script though:
domain='example.org'
ledir="/etc/letsencrypt/live/$domain"
cabundle="$ledir/chain.pem"
crt="$ledir/cert.pem"
key="$ledir/privkey.pem"
cpanel_host='cpanel.example.com:2083'
cpanel_user=''
curl -u "$cpanel_user"\
"$cpanel_host/json-api/cpanel?cpanel_jsonapi_apiversion=2&cpanel_jsonapi_module=SSL&cpanel_jsonapi_func=installssl&cpanel_jsonapi_user=$cpanel_user"\
-d "domain=$domain" --data-urlencode "cabundle#$cabundle" --data-urlencode "crt#$crt" --data-urlencode "key#$key"
This will still ask for your password. But it is possible to provide Curl with the password as well: curl -u "user:password" ...
you should look windows "sheduled tasks"
https://sites.google.com/site/ballif1073/windows/taches-planifiees
command line Example, not sure its working as i wrote it from the doc on my linux systeme :) (run task every month):
C:\>SCHTASKS /Create /SC MONTHLY /TR C:\path\to\letsencrypt-win-simple.exe
I'm setting up a domain registry as described here:
https://docs.docker.com/registry/deploying/
I generated a certificate for docker.mydomain.com and started the docker using their command on my server:
docker run -d -p 5000:5000 --restart=always --name registry \
-v `pwd`/certs:/certs \
-e REGISTRY_HTTP_TLS_CERTIFICATE=/certs/domain.crt \
-e REGISTRY_HTTP_TLS_KEY=/certs/domain.key \
registry:2
I've started the docker and pointed to certificates I obtained using letsencrypt (https://letsencrypt.org/).
Now, when I browse to https://docker.mydomain.com:5000/v2/ I will get a page with just '{}', with a green lock (succesful secure page request).
But when I try to do a docker login docker.mydomain.com:5000 from a different server I see a error in the registry docker:
TLS handshake error from xxx.xxx.xxx.xxx:51773: remote error: bad certificate
I've tried some different variations in setting up the certificates, and gotten errors like:
remote error: unknown certificate authority
and
tls: first record does not look like a TLS handshake
What am I missing?
Docker seams to not support SNI : https://github.com/docker/docker/issues/9969
Update : Docker now should support SNI.
It's mean, when connecting to your server during the tls transaction, the docker client do not specify the domain name, so your server show the default certificate.
The solution could be to change to default certificate of your server to be to one valid for the docker domain.
This site works only in browsers with SNI support.
To check if your (sub-)domain works with clients not SNI-aware, you can use ssllabs.com/ssltest : If you DONT see the message, "This site works only in browsers with SNI support. " then it will works.
I followed the Docker Registry installation docs precisely, and have a registry running on a remote Ubuntu VM. On that VM, the Docker container is running with the following command:
docker run -d -p 5000:5000 --restart=always --name registry \
-v `pwd`/auth:/auth \
-e "REGISTRY_AUTH_HTPASSWD_REALM=Registry Realm" \
-e REGISTRY_AUTH_HTPASSWD_PATH=/auth/htpasswd \
-v `pwd`/certs:/certs \
-e REGISTRY_HTTP_TLS_CERTIFICATE=/certs/registry.crt \
-e REGISTRY_HTTP_TLS_KEY=/certs/registry.key \
registry:2
On the remote VM, I have the following directory structure:
/home/myuser/
certs/
registry.crt
registry.key
/etc/docker/certs.d/myregistry.example.com:5000/
ca.crt
ca.key
The ca.crt is the same exact cert as ~/certs/registry.crt (just renamed); same goes for ca.key and registry.key being the same/just renamed. I created the ca* files per a suggestion from the error output you'll see below.
I am almost 100% sure the CA cert is still valid, although any help ruling that out (e.g. how can I actually tell?) would be appreciated. When I start the container and look at the Docker logs, I don't see any errors.
I then attempt to login from my local laptop (Mac):
docker login myregistry.example.com:5000
It queries me for my username, password and email (although I don't recall ever specifying an email when setting up Basic Auth). After entering these correctly (I have checked and double checked...) I get the following error:
myuser#mymachine:~/tmp$docker login myregistry.example.com:5000
Username: my_ciuser
Password:
Email: myuser#example.com
Error response from daemon: invalid registry endpoint https://myregistry.example.com:5000/v0/:
unable to ping registry endpoint https://myregistry.example.com:5000/v0/ v2 ping attempt failed with error:
Get https://myregistry.example.com:5000/v2/: x509: certificate has expired or is not yet valid
v1 ping attempt failed with error: Get https://myregistry.example.com:5000/v1/_ping: x509:
certificate has expired or is not yet valid. If this private registry supports only HTTP or
HTTPS with an unknown CA certificate, please add
`--insecure-registry myregistry.example.com:5000` to the daemon's
arguments. In the case of HTTPS, if you have access to the registry's CA
certificate, no need for the flag; simply place the CA certificate
at /etc/docker/certs.d/myregistry.example.com:5000/ca.crt
So from my perspective, I guess the following are possible:
The CA cert is invalid (if so, why?!?)
The CA cert is an intermediary cert (if so, how can I tell?)
The CA cert is expired (if so, how do I tell?)
This is a bad error message, and some other facet of the registry is not configured properly (if so, how do I troubleshoot further?)
Perhaps my cert is not located in the correct place on the server, or doesn't have the right permissions set (if so, where does the cert need to be?)
Something else that I would never expect in a million years
Any ideas/thoughts?
As said in the error message:
... In the case of HTTPS, if you have access to the registry's CA
certificate, no need for the flag; simply place the CA certificate
at /etc/docker/certs.d/myregistry.example.com:5000/ca.crt
where myregistry.example.com:5000 - your CN with port.
You should copy your ca.crt into each Docker Daemon that will connect to your Docker Registry and put it in this folder: /etc/docker/certs.d/myregistry.example.com:5000/ca.crt
After this action you need to restart Docker daemon, for example, via sudo service docker stop && service docker start on CentOS (or call similar procedure on your OS).
I had the similar error:
Then I added my private registry to the insecureregistries list.
See below image for docker-desktop