We are able to create azure api manager. it has default azure specific urls for management,portal, proxy,scm.
we want to change these URLs to different format.is it possible for someone provide steps for getting pfx file mainly from letsencrypt.
as per my understanding we need to use for getting certificates
sudo -H ./letsencrypt-auto certonly --standalone -d mycustomdomain.com
consider for example mycustomdomain.com is proxy url for which we need to generate certificate.
this url must be present as A name in some dns system. but since our url is not associated with any IP or other record we can not proceed in this case.
.
I can't help you with LetsEncrypt, but for APIM's custom domains you should not create A record in DNS, instead you create CNAME record for your custom domain that points to default APIM hostname, i.e. xxx.azure-api.net. You could go for A record and use APIM's IP address, but that would not be stable as IP may change if some disaster occurs, and will change if service deleted/undeleted, or joined/removed from vnet.
Here are steps to create pfx certificate with letsencrypt.
Problem statement
Azure API management service provide default url for accessing backend API.This url is known as proxy url and has format like .azure.api.net.
Azure also provide facility to create custom url by providing url name, pfx certificate and certificate password.
Steps to generate pfx file
install certbot on your ubantu box (you can check similar steps online for other OS)
sudo apt-get update
sudo apt-get install software-properties-common
sudo add-apt-repository universe
sudo add-apt-repository ppa:certbot/certbot
sudo apt-get update
sudo apt-get install certbot
retrieve txt record
certbot -d api.mycompanydomain.com --manual --preferred-challenges dns certonly
It will provide txt value to add in our azure dns zone. Please add same in dns zone as txt value. Once done click enter. It will generate certificates in /etc/letsencrypt/live/api.mycompanydomain.com
create pfx file
visit /etc/letsencrypt/live/api.mycompanydomain.com and run following command
sudo openssl pkcs12 -export -out api.mycompanydomain.com.pfx -inkey privkey.pem -in cert.pem -certfile chain.pem
it will create pfx file in current working directory which you can use while creating custom domains
map default proxy url to custom url as cname
once you configure this custom url you can map your custom url to default url in azure dns zone.
Related
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/
I'm new to Linux, just installed Lubuntu and faced the problem -
when i'm trying to clone my remote work repo from my company's git:
$ sudo git clone https://path/to/repo.git
I keep on receiving error:
Cloning into 'repo'...
fatal: unable to access 'https://path/to/repo.git/': server certificate verification failed. CAfile: none CRLfile: none
I know it's mentioning certificates, but i do not have any. And before, i worked on windows and was able to simply git clone this repo without any certs.
This error means that the git client cannot verify the integrity of the certificate chain or root. The proper way to resolve this issue is to make sure the certificate from the remote repository is valid, and then added to the client system.
Update list of public CA
The first thing I would recommend is to simply update the list of root CA known to the system as show below.
# update CA certificates
sudo apt-get install apt-transport-https ca-certificates -y
sudo update-ca-certificates
This may help if you are dealing with a system that has not been updated for a long time, but of course won’t resolve an issue with private certs.
Fetch certificates, direct connection
The error from the git client will be resolved if you add the certs from the remote git server to the list of locally checked certificates. This can be done by using openssl to pull the certificates from the remote host:
openssl s_client -showcerts -servername git.mycompany.com -connect git.mycompany.com:443 </dev/null 2>/dev/null | sed -n -e '/BEGIN\ CERTIFICATE/,/END\ CERTIFICATE/ p' > git-mycompany-com.pem
This will fetch the certificate used by “https://git.mycompany.com”, and copy the contents into a local file named “git-mycompany-com.pem”.
Fetch certificates, web proxy
If this host only has access to the git server via a web proxy like Squid, openssl will only be able to leverage a squid proxy if you are using a version of OpenSSL 1.1.0 and higher. But if you are using an older version of OpenSSL, then you will need to workaround this limitation by using something like socat to bind locally to port 4443, and proxy the traffic through squid and to the final destination.
# install socat
sudo apt-get install socat -y
# listen locally on 4443, send traffic through squid "squidhost"
socat TCP4-LISTEN:4443,reuseaddr,fork PROXY:squidhost:git.mycompany.com:443,proxyport=3128
Then in another console, tell OpenSSL to pull the certificate from the localhost at port 4443.
openssl s_client -showcerts -servername git.mycompany.com -connect 127.0.0.1:4443 </dev/null 2>/dev/null | sed -n -e '/BEGIN\ CERTIFICATE/,/END\ CERTIFICATE/ p' > git-mycompany-com.pem
Add certificate to local certificate list
Whether by proxy or direct connection, you now have a list of the remote certificates in a file named “git-mycompany-com.pem”. This file will contain the certificate, its intermediate chain, and root CA certificate.
The next step is to have this considered by the git client when connecting to the git server. This can be done by either adding the certificates to the file mentioned in the original error, in which case the change is made globally for all users OR it can be added to this single users’ git configuration.
** Adding globally **
cat git-mycompany-com.pem | sudo tee -a /etc/ssl/certs/ca-certificates.crt
** Adding for single user **
git config --global http."https://git.mycompany.com/".sslCAInfo ~/git-mycompany-com.pem
Which silently adds the following lines to ~/.gitconfig
[http "https://git.mycompany.com/"]
sslCAInfo = /home/user/git-mycompany-com.pem
Avoid workarounds
Avoid workarounds that skip SSL certification validation. Only use them to quickly test that certificates are the root issue, then use the sections above to resolve the issue.
git config --global http.sslverify false
export GIT_SSL_NO_VERIFY=true
I know there is an answer already. Just for those who use a private network, like Zscaler or so, this error can occur if your rootcert needs to be updated. Here a solution on how this update can be achieve if using WSL on a Windows machine:
#!/usr/bin/bash
# I exported the Zscaler certifcate out of Microsoft Cert Manager. It was located under 'Trusted Root Certification > Certificates' as zscaler_cert.cer.
# Though the extension is '.cer' it really is a DER formatted file.
# I then copied that file into Ubuntu running in WSL.
# Convert DER encoded file to CRT.
openssl x509 -inform DER -in zscaler_cert.cer -out zscaler_cert.crt
# Move the CRT file to /usr/local/share/ca-certificates
sudo mv zscaler_cert.crt /usr/local/share/ca-certificates
# Inform Ubuntu of new cert.
sudo update-ca-certificates
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 have an SSL certificate issued by https://letsencrypt.org/ . It will be expiring tomorrow and I am having trouble renewing it. I have spun up a fresh linux box, installed certbot (as per https://letsencrypt.org/getting-started/ ) . I have the following saved in a local directory:
cert.pem
chain.pem
fullchain.pem
privkey.pem
Within the directory that contains the certificate I then run
/path/to/certbot/certbot-auto renew --dry-run --force-renew
certbot appears to not find the certificates as it then says
No renewals were attempted.
I have also run
/path/to/certbot/certbot-auto renew --force-renew
and get the same response.
Is there a way to renew certificates that are not stored in the expected /letsencrypt/archive/... folder as is the case for a fresh installation on a fresh box?
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.