Note: I've tried to keep things as simple as possible in this question as that is as far as my knowledge goes. Any form of help is appreciated
I'm new to FreeIPA and I struggle to request a SSL certificate and key file from FreeIPA as Certificate Authority.
I verify I get a krbtgt using klist using the credentials of Certificate Admin.
$ klist
Valid starting Expires Service principal
01/05/2022 5:35:35 01/06/2022 5:35:35 krbtgt/MYDOM#MYDOM
renew until 01/12/2022 5:35:35
sudo /usr/bin/ipa-getcert request -r -w -k /tmp/test.key \
-f /tmp/test.cert.pem \
-g 4096
-K HTTP/service.mydom \
-T caIPAserviceCert \
-D test.myDom -N CN=test.myDom,O=MYDOM
New signing request "20220105093346" added.
Only thing being created is the private key:
$ ls /tmp
test.key
Why isn't the certificate being created ? Insufficient privileges.
Error:
$ sudo getcert list
Number of certificates and requests being tracked: 1.
Request ID '20220105093346':
status: CA_REJECTED
ca-error: Server at https://idm.myDom/ipa/xml denied our request, giving up: 2100 (RPC failed at server. Insufficient access: Insufficient 'write' privilege to the 'userCertificate' attribute of entry 'krbprincipalname=HTTP/service.mydom#MYDOM,cn=services,cn=accounts,dc=mydom'.).
stuck: yes
key pair storage: type=FILE,location='/tmp/test.key'
certificate: type=FILE,location='/tmp/test.cert.pem'
CA: IPA
issuer:
subject:
expires: unknown
pre-save command:
post-save command:
track: yes
auto-renew: yes
Though I am able to run
$ ipa service-mod HTTP/service.mydom --certificate=
Possible duplicatae freeipa-request-certificate-with-cname
Any ideas?
Turns out the machine I am requesting the certificate from needs to be allowed to manage the web service for web host.
Only the target machine can create a certificate (IPA uses the host
kerberos ticket) by default, so to be able to create the certificate
on your IPA server you need to allow it to manage the web service for
the www host.
[root#ipa-server ~]# ipa service-add-host --hosts=ipa-server.test.lan HTTP/www.test.lan
Source:
Creating certs and keys for services using freeipadogtag/
Related
In my Azure Linux web app, I'm trying to perform an API call to an external provider, with a certificate. That call fails, while it's working fine when deploying the same code on a Windows app service plan. The equivalent cURL command line is:
curl --cert-type p12 --cert /var/ssl/private/THUMBPRINT.p12 -X POST https://www.example.com
The call fails with the following error:
curl: (58) could not load PKCS12 client certificate, OpenSSL error error:140AB18E:SSL routines:SSL_CTX_use_certificate:ca md too weak
The issue is caused by OpenSSL 1.1.1d, which by defaults requires a security level of 2, and my certificate is signed with SHA1 with RSA encryption:
openssl pkcs12 -in THUMBPRINT.p12 -nodes | openssl x509 -noout -text | grep 'Signature Algorithm'
Signature Algorithm: sha1WithRSAEncryption
Signature Algorithm: sha1WithRSAEncryption
On a normal Linux VM, I could edit /etc/ssl/openssl/cnf to change
CipherString = DEFAULT#SECLEVEL=2
to security level 1, but on an Azure Linux web app, the changes I make to that file are not persisted..
So my question is: how do I change the OpenSSL security level on an Azure web app? Or is there a better way to allow the use of my weak certificate?
Note: I'm not the issuer of the certificate, so I can't regenerate it myself. I'll check with the issuer if they can regenerate it, but in the meantime I'd like to proceed if possible :)
A call with Microsoft support led me to a solution. It's possible to run a script whenever the web app container starts, which means it's possible to edit the openssl.cnf file before the dotnet app in launched.
To do this, navigate to the Configuration blade of your Linux web app, then General settings, then Startup command:
The Startup command is a command that's ran when the container starts. You can do what you want, but it HAS to launch your app, because it's no longer done automatically.
You can SSH to your Linux web app, and edit that custom_startup.sh file:
#!/usr/sh
# allow weak certificates (certificate signed with SHA1)
# by downgrading OpenSSL security level from 2 to 1
sed -i 's/SECLEVEL=2/SECLEVEL=1/g' /etc/ssl/openssl.cnf
# run the dotnet website
cd /home/site/wwwroot
dotnet APPLICATION_DLL_NAME.dll
The relevant doc can be found here: https://learn.microsoft.com/en-us/azure/app-service/containers/app-service-linux-faq#built-in-images
Note however that the Startup command is not working for Azure Functions (at the time of writing May 19th, 2020). I've opened an issue on Github.
To work around this, I ended up creating custom Docker images:
Dockerfile for a webapp:
FROM mcr.microsoft.com/appsvc/dotnetcore:3.1-latest_20200502.1
# allow weak certificates (certificate signed with SHA1)
# by downgrading OpenSSL security level from 2 to 1
RUN sed -i 's/SECLEVEL=2/SECLEVEL=1/g' /etc/ssl/openssl.cnf
Dockerfile for an Azure function:
FROM mcr.microsoft.com/azure-functions/dotnet:3.0.13614-appservice
# allow weak certificates (certificate signed with SHA1)
# by downgrading OpenSSL security level from 2 to 1
RUN sed -i 's/SECLEVEL=2/SECLEVEL=1/g' /etc/ssl/openssl.cnf
I followed this tutorial to create a point-to-site connection:
https://learn.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-howto-point-to-site-resource-manager-portal
Now, when i try to connect the VPN I get this error:
A certificate could not be found that can be used with this Extensible Authentication Protocol. (Error 798)
It doesn't even work in the computer that I generated the self-signed cert. Neither it works in another client that I installed the pfx private key and fails in both with the same error.
Any ideas?
Ok turns out the document to create the certs are not complete here and not mentioning anything about the client cert and it just says how to create a root cert:
https://learn.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-certificates-point-to-site
Here is what I had to do to make it work:
Create root cert:
makecert -sky exchange -r -n "CN=AzureRootCert" -pe -a sha1 -len 2048 -ss My "AzureRootCert.cer"
Create client cert:
makecert.exe -n "CN=AzureClientCert" -pe -sky exchange -m 96 -ss My -in "AzureRootCert" -is my -a sha1
Then the rest is documented. so have to export the root cert and upload to Azure and then download the VPN tool.
I was trying to install gitlab on my linux server following this guide and got stucked in the second setp that says
curl: (60) SSL certificate problem: self signed certificate
More details here: http://curl.haxx.se/docs/sslcerts.html
curl performs SSL certificate verification by default, using a "bundle"
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn't adequate, you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
the -k (or --insecure) option.
any idea on how can I solve this?
ANSWER be sure to have http_proxy and https_proxy variables correctly set.
---- UPDATE ----
After setting the variables I got the following answer from curl
Detected operating system as Ubuntu/trusty.
Checking for curl...
Detected curl...
Running apt-get update... done.
Installing apt-transport-https... done.
Installing /etc/apt/sources.list.d/gitlab_gitlab-ce.list...curl: (60) SSL certificate problem: self signed certificate
More details here: http://curl.haxx.se/docs/sslcerts.html
curl performs SSL certificate verification by default, using a "bundle"
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn't adequate, you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
the -k (or --insecure) option.
Unable to run:
curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/config_file.list?os=Ubuntu&dist=trusty&source=script
Double check your curl installation and try again.
Tell curl to ignore SSL warnings with -k/--insecure. Documented in man curl.
Edit: also check your proxy settings, as the host you're trying to curl to does, in fact, have a valid SSL certificate. See the --proxy option of curl.
I am trying to find out why my HTTPS link is not working for my website:
So I ran this command to try:
curl https://localhost/
I am using a valid signed SSL certificate and my HTTP link is working fine. I am using a Multi Domain certificate that was exported from an IIS 6 server. My instance on AWS has the 443 port enabled.
Here is a picture of my CA certificates:
I have tried to change the http.conf file's Virtual Host following the instructions in here: http://ananthakrishnanravi.wordpress.com/2012/04/15/configuring-ssl-and-https-for-your-website-amazon-ec2/
Is there any suggestions on how to get my website properly working on a HTTPS protocol?
Let me know if you need anymore information.
Thanks,
If you're not sure of the certificate that your web server is serving, you can use this command to view the certificate:
openssl s_client -showcerts -connect hostname.domain.tld:443
Also, the hostname in the certificate must match the site that you are requesting. For example, if you request a page from localhost, but your certificate is for www.yourdomain.com, the certificate check will fail.
This means that you are using a self-signed certificate.
In order for this warning not to appear, you need to purchase a certificate from a Certificate Authority.
If you are using Self Signed SSL certificate then you faced this issue.
For this you can use curl command with -k option.
curl -k https://yourdomain.com/
And if you are trying with Postman that time disable the SSL Certificate option in setting.
I got a same error but not similar to your, but summary here hope useful for others:
OS: CentOS 7
Run Python's pyspider error:
File "/usr/local/lib64/python3.6/site-packages/tornado/concurrent.py", line 238, in result
raise_exc_info(self._exc_info)
File "", line 4, in raise_exc_info
Exception: HTTP 599: Peer's certificate issuer has been marked as not trusted by the user.
root cause and steps to fix:
previously existed a soft link:
/usr/lib64/libcurl.so.4 -> /usr/lib64/libcurl.so.4.3.0_openssl
which is invalid one, so changed to valid:
/usr/lib64/libcurl.so.4 -> /usr/lib64/libcurl.so.4.3.0
while two file is:
-rwxr-xr-x 1 root root 435192 Nov 5 2018 /usr/lib64/libcurl.so.4.3.0
-rwxr-xr-x 1 root root 399304 May 10 09:20 /usr/lib64/libcurl.so.4.3.0_openssl
then for pyspider reinstall pycurl:
pip3 uninstall pycurl
export PYCURL_SSL_LIBRARY=nss
export LDFLAGS=-L/usr/local/opt/openssl/lib;export CPPFLAGS=-I/usr/local/opt/openssl/include;pip install pycurl --compile --no-cache-dir
in which PYCURL_SSL_LIBRARY is nss, due to current curl backend is nss according to
# curl --version
curl 7.29.0 (x86_64-redhat-linux-gnu) libcurl/7.29.0 NSS/3.36 zlib/1.2.7 libidn/1.28 libssh2/1.4.3
...
can fix my problem.
I have a situation where the client makes a call through curl to a https url. The SSL certificate of the https url is self signed and therefore curl cannot do certificate validation and fails. curl provides an option -k/--insecure which disables certificate validation.
My question is that on using --insecure option, is the data transfer that is done between client and server encrypted(as it should be for https urls)? I understand the security risk because of certificate validation not being done, but for this question I am only concerned about whether data transfer is encrypted or not.
Yes, the transfered data is still sent encrypted. -k/--insecure will "only make" curl skip certificate validation, it will not turn off SSL all together.
More information regarding the matter is available under the following link:
curl.haxx.se - Details on Server SSL Certificates
It will be encrypted but insecure. If you trust the certificate you should add the certificate to your certificate store instead of connecting insecurely.
macOS:
sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain ~/new-root-certificate.crt
Ubuntu, Debian:
sudo cp foo.crt /usr/local/share/ca-certificates/foo.crt
sudo update-ca-certificates
CentOS 6:
yum install ca-certificates
update-ca-trust force-enable
cp foo.crt /etc/pki/ca-trust/source/anchors/
update-ca-trust extract
CentOs 5:
cat foo.crt >>/etc/pki/tls/certs/ca-bundle.crt
Windows:
certutil -addstore -f "ROOT" new-root-certificate.crt