I have a server on Linode with 1-click install (Debian 9) .
After that I install Lets Encrypt by following Certbot official procedures.
https://certbot.eff.org/lets-encrypt/debianstretch-apache
Everything works ok without any error. However, when i add another domain to the same server, it get warning by saying this new site is "Not Secure"
By checking the following files
/etc/letsencrypt/live
I only manage to see my1stdomain.com So i think this is the main reason for the my2nddomain.com to receive a warning "Not Secure"
I can't find the official docs for add new domains on certbot.eff.org
What i found the most likely to be the correct way to add new domains are this command line
sudo -H ./letsencrypt-auto certonly --standalone -d my2nddomain.com -d www.my2nddomain.com
However, i don't dare to test it yet because I am afraid it may get error and cause the whole server not working. By then, my 1stdomain will also be effected.
Anyone can advice ?
Related
I have a script that runs every day on an Ubuntu 14.04 server. The script is a simple wget command that downloads a file from a remote server and saves it to the local file system:
wget https://example.com/resources/scripts/myfile.php -O myfile.php
It has worked fine for months until this morning when suddenly when I run it I get:
--2020-05-30 11:57:16-- https://example.com/resources/scripts/myfile.php
Resolving example.com (example.com)... xx.xx.xx.xx
Connecting to example.com (example.com)|xx.xx.xx.xx|:443... connected.
ERROR: cannot verify example.com's certificate, issued by ‘/C=GB/ST=Greater Manchester/L=Salford/O=Sectigo Limited/CN=Sectigo RSA Domain Validation Secure Server CA’:
Issued certificate has expired.
To connect to example.com insecurely, use `--no-check-certificate'.
The SSL for the domain is valid and expires in Jan. 2022. Nothing has changed on that front. And yet somehow wget no longer sees that.
Here is another interesting fact. If I run this same exact command on an Ubuntu 18 box, it works like a charm without any complaints. This tells me something is wrong with my Ubuntu 14.04 machine.
Curl produces the same error:
curl https://example.com
curl: (60) SSL certificate problem: certificate has expired
This post suggest that the certificate bundle is out of date. I have downloaded the suggested PEM file and tried running wget with by specifying the --ca-certificate=cacert.pem option, but to no avail.
I have also tried running: apt install ca-certificates and update-ca-certificates, but that did not work either.
Again, everything works great on an Ubuntu 18 box, but not Ubuntu 14 or 16. Also why did it work fine until this morning when I know nobody has touched the box? Clearly something is out of date, but I can't seem to figure out how to fix it.
Does anybody have any suggestions?
I had the same error two days ago with Comodo Certificate and ubuntu 16.04.
The problem was like say mrmuggles this https://support.sectigo.com/Com_KnowledgeDetailPage?Id=kA03l00000117LT.
I fixed with this steps:
vi /etc/ca-certificates.conf
Remove the line (or comment)
specifying AddTrust_External_Root.crt
apt update && apt install ca-certificates
update-ca-certificates -f -v
https://askubuntu.com/questions/440580/how-does-one-remove-a-certificate-authoritys-certificate-from-a-system
Like the original poster the method of editing ca-certificates.conf did not work for me on Ubuntu 14.04.
What did work:
Run sudo dpkg-reconfigure ca-certificates
Deselect the problem CA: AddTrust_External_Root
Press OK
My understanding is that deletes the expired CA of AddTrust_External_Root and the newer CA USERTrust_RSA_Certification_Authority is used instead.
For wget add --no-check-certificate
Example: wget https://example.com/resources/scripts/myfile.php --no-check-certificate -O myfile.php
I would like to deploy my Meteor app to Heroku and make it only accessible through HTTPS. Ideally, I want to do this as cheaply as possible.
Create the Certificate
Run these commands to get certbot-auto. certbot-auto should work on most systems
wget https://dl.eff.org/certbot-auto
chmod 755 certbot-auto
This command starts the process of getting your certificate. The -d flag allows you to pass in the domain you would like to secure. Alternatively, without the -d flag, it will pop up a prompt where you can enter the domain.
./certbot-auto certonly --manual -d app.yoursite.com
Then it will ask you the following. Do not hit enter.
Make sure your web server displays the following content at
http://app.yoursite.com/.well-known/acme-challenge/SOME-LENGTHY-KEY before continuing:
SOME-LONGER-KEY
Use Picker
I suggest using this method because on renewal, you will only need to update an environment variable. You can use public/ as below, but it will require a rebuild of your entire app every time
Run meteor add meteorhacks:picker
In a server side file, add the following
import { Picker } from 'meteor/meteorhacks:picker';
Picker.route('/.well-known/acme-challenge/:routeKey', (params, request, response) => {
response.writeHead('200', {'Content-Type': 'text/plain'});
response.write(process.env.SSL_PAGE_KEY)
response.end();
});
Then set an environment variable SSL_PAGE_KEY to SOME-LONGER-KEY with
heroku config:set SSL_PAGE_KEY=SOME-LONGER-KEY
Use public/
Create the directory path in your public folder. If you don't have one, create one.
mkdir -p public/.well-known/acme-challenge/
Then create the file SOME-LENGTHY-KEY and place SOME-LONGER-KEY inside it
echo SOME-LONGER-KEY > public/.well-known/acme-challenge/SOME-LENGTHY-KEY
Commit and push that change to your Heroku app.
git push heroku master
Now hit enter to continue the verification process. You should receive a message like this
IMPORTANT NOTES:
- Congratulations! Your certificate and chain have been saved at
/etc/letsencrypt/live/app.yoursite.com/fullchain.pem. Your cert will
expire on 2016-04-11. To obtain a new version of the certificate in
the future, simply run Let's Encrypt again.
Upload the Certificate
To upload your certificates to Heroku, first enable the SSL Beta
heroku labs:enable http-sni -a your-app
heroku plugins:install heroku-certs
Then add your fullchain.pem and privkey.pem to Heroku.
sudo heroku _certs:add /etc/letsencrypt/live/app.yoursite.com/fullchain.pem /etc/letsencrypt/live/app.yoursite.com/privkey.pem
You can verify that the certificate was uploaded with
heroku _certs:info
Change your DNS Settings
Update your DNS to point to app.yoursite.com.herokudns.com
Verify SSL is working
To check that SSL is set up, run the following. -v gives you verbose output. -I shows the document info only. -H passes a header to the URL. The header we're passing ensures that a cache is not being used and will ensure you get your new certificate and not an old one.
curl -vI https://app.yoursite.com -H "Cache-Control: no-cache"
Check that the output contains the following
* Server certificate:
* subject: C=US; ST=CA; L=SF; O=SFDC; OU=Heroku; CN=app.yoursite.com
If the subject line does not contain CN=app.yoursite.com, wait 5 to 10 minutes and try again. If it does, you're almost good to go.
Make Meteor Specific Changes
To finish up the process, you'll want to change your ROOT_URL environment variable to the new https version.
heroku config:set ROOT_URL=https://app.yoursite.com
Then you'll want to ensure that your users are always using SSL with the force-ssl package
meteor add force-ssl
Lastly, if you have any OAuth logins set up in your app (Facebook, Google, etc), you'll want to provide them with the new https version of your URL.
Renewal
Run certbot-auto again
./certbot-auto certonly --manual -d app.yoursite.com
It may prompt you for the same endpoint with the same content. If it does, just hit enter. If it does not, you will need to repeat the above steps.
It will then create new certificate files, which you will upload to Heroku with
heroku certs:update /etc/letsencrypt/live/app.yoursite.com/fullchain.pem /etc/letsencrypt/live/app.yoursite.com/privkey.pem
Then to confirm, run the Verify SSL is working commands above
Sources
https://certbot.eff.org/#ubuntutrusty-other
https://devcenter.heroku.com/articles/ssl-beta
https://themeteorchef.com/blog/securing-meteor-applications/
I am trying to configure loggly in apache in my ubuntu machine.
What I have done is
curl -O https://www.loggly.com/install/configure-apache.sh
sudo bash configure-apache.sh -a XXXXXX -u XXXXXX
After entering the last line it's saying
ERROR: Apache logs did not make to Loggly in time. Please check network and firewall settings and retry.
Manual instructions to configure Apache2 is available at https://www.loggly.com/docs/sending-apache-logs/. Rsyslog troubleshooting instructions are available at https://www.loggly.com/docs/troubleshooting-rsyslog/
Any idea why it's showing and how to solve it?
This is likely a network issue or a delay in sending the logs or even an issue with the script. Check out the following link that has the manual instructions. https://www.loggly.com/docs/sending-apache-logs/ that you can follow and use to verify the script created the configuration files correctly.
Want to use ldap_mod_add command with SSL on Centos but get the following error message;
PHP Warning: ldap_mod_add (): Modify: Server is unwilling to perform in ...
However the SSL ldapsearch command is working well;
ldapsearch -x -H ldaps://winsvr.intra -b dc=windows, dc=intra -D "DOMAIN\user"-w "123456"
The required Windows.pem file is in /etc/ssl/certs/windows.pem directory and has the appropriate line in /etc/openldap/ldap.conf.
Indeed getting above error message.
What else should I configure to work properly?
Updated:
Everything's OK. Problem was that I didn't recognize existing AD user. That's why the ldap_mod_add returned with above error messages (it couldn't add same AD user through ldap_mod_add).
The LDAP client in your PHP example is apparently doing an update, whereas the ldapsearch tool is doing a search, not to point too fine a point on it. The configuration of the server, the nature of the target entries involved, and any access controls involved might affect the update but not the search.
I am trying to setup jenkins, but I cant get the authentication to work. I am running jenkins on Tomcat6 on CentOS 6.2. I enable logging in, and everything goes fine until I try to log in. After giving my credential and pressing login, tomcat gives me a error:
"HTTP Status 404 - The requested resource () is not available." on http://myserver:8080/jenkins/j_acegi_security_check
By googling I can find this:
https://issues.jenkins-ci.org/browse/JENKINS-3761
Two suggested fixes I have found:
Run jenkins on tomcat instead of running the standalone version - I
am already doing so.
Edit a file: WEB-INF/security/SecurityFilters.groovy - I tried to
edit, but I can't get it to change anything
Is there something I could do to make this work?
Spent ages wrestling with this one, make sure a Security Realm is set when you are choosing your Authorization method in Jenkins.
That is, in Manage Jenkins → Configure Global Security select an option in the Security Realm list.
For example:
You may have forgotten to select a Security Realm as specified below
https://wiki.jenkins-ci.org/display/JENKINS/Standard+Security+Setup
In case you have locked yourself out, you can revert the Jenkins config.xml file to set <useSecurity>true</useSecurity> node value to false by following instructions here
https://wiki.jenkins-ci.org/display/JENKINS/Disable+security
As mentioned on the bug page:
The error was caused by a proxy pass rule "/jenkins http://localhost:9080/jenkins/" which led to the incomming (jenkins) request "/jenkins//j_acegi_security_check" (double //). So the login page was rejected with 404 (while all other pages where served).
Make sure your /jenkins ProxyPass does not end with a trailing slash in the destination URL.
I had the same problem with 404 on the "/jenkins/j_acegi_security_check" page.
Using Jenkins with Tomcat, after a lot of tries to solve it, I came to following solution - I´m using 18080 as default port without SSL-redirection.
It´s related to the redirection, but in that case (as using Tomcat) it has to be changed in the tomcat-server-configuration:
Look in /conf/server.xml for the following entry:
<Connector port="18080" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443" />
Just commenting out the redirectPort helped for me:
<Connector port="18080" protocol="HTTP/1.1"
connectionTimeout="20000" />
I had the same HTTP 404 on the "/jenkins/j_acegi_security_check" URI problem .
And the same issue as pointed out by pga above: Tomcat was being started as user root.
This was because I had setup tomcat to restart automatically by creating a startup tomcat script at "/etc/init.d/".
Fixed the issue with:
su - tomcatuser - c /cde/pkgs/../tomcat/start.sh
I was facing the same issue on Ubuntu as well as on AIX, where I desperately needed it to work in production settings. I even tried Tomcat and Apache web servers, still the same issue.
Finally changing the class loader as follows made it work in stand-alone mode:
java -jar jenkins.war --httpPort=79802 --preferredClassLoader=java.net.URLClassLoader &
By the way, this is default settings in standard Jenkins distribution for Ubuntu, from where I got the clue.
Probably the issue is related with packaging, but for now this solution works. Check if this resolves similar issues.
My bookmarked jenkins login url was: https://jenkins.foo.com/login?from=%2F
If security is disabled and you hit that url with any credentials or blank ones, it brings up the j_acegi error.
Instead, use https://jenkins.foo.com/ and it will take you straight to the dashboard.
I had the same HTTP 404 on the "/jenkins/j_acegi_security_check" URI.
In my case, Jenkins was running on a Tomcat started by user 'root'. Stopped Tomcat, and started it again by the proper separate application user. Problem solved.
Seeing vote down: I did the steps again on fresh server.
There were ** characters and I removed that
There were missing $sign for tomcat like this $TOMCAT_VERSION
(Both corrected and it is working) (updated on 28.03.2016)
Disable the security as given below:
http://markunsworth.com/2012/02/13/locked-yourself-out-of-jenkins/
Unable to login jenkins, and can't disable login option either
Or
Locked in login with Jenkins on Tomcat.
http://xx.xxx.xxx.xxx:8080/jenkins/login?from=/jenkins/ and after filling the userId Password, which was not set up at all, will always take to this page
http://xx.xxx.xxx.xxx:8080/jenkins/j_acegi_security_check
HTTP Status 404 - description The requested resource is not available.
I had .war file installed in tomcat
It took me long to fix this issue.
I had many times completely removed Tomcat, Jenkins all folders .jenkins etc reinstalled and what not...
Remove both Tomcat and Jenkins completely once again...
The solution is proper use of user and group, let us see how to it by running the following commands one by one.
You are logged in with user(e.g. vimal) with sudo permission.
vimal#h123:~$ sudo apt-get update
vimal#h123:~$ BASE_USER=vimal
vimal#h123:~$ sudo chown -Rf $BASE_USER:$BASE_USER /opt/
vimal#h123:~$ USER=apache-tomcat
vimal#h123:~$ GROUP=myjenkins
vimal#h123:~$ TOMCAT_INSTALL_DIR=/opt
vimal#h123:~$ TOMCAT_VERSION=apache-tomcat-8.0.23
vimal#h123:~$ TOMCAT_URL=http://archive.apache.org/dist/tomcat/tomcat-8/v8.0.23/bin/apache-tomcat-8.0.23.zip
For TOMCAT_URL, copy the link that you need from archive/src (.zip) of tomcat download site
vimal#h123:~$ mkdir -p $TOMCAT_INSTALL_DIR
vimal#h123:~$ cd $TOMCAT_INSTALL_DIR
vimal#h123:~$ wget $TOMCAT_URL
vimal#h123:~$ unzip -q $TOMCAT_VERSION.zip
vimal#h123:~$ rm $TOMCAT_VERSION.zip
Before running command below you need to have JAVA_HOME set up in like JAVA_HOME="/usr/lib/jvm/java-8-oracle/" by adding this into
sudo nano /etc/environment
vimal#h123:~$ sudo chmod +x $TOMCAT_INSTALL_DIR/$TOMCAT_VERSION/bin/*.sh
vimal#h123:~$ $TOMCAT_INSTALL_DIR/$TOMCAT_VERSION/bin/catalina.sh start
vimal#h123:~$
vimal#h123:~$ cd $TOMCAT_INSTALL_DIR/$TOMCAT_VERSION/webapps/
vimal#h123:~$ wget http://mirrors.jenkins-ci.org/war-stable/latest/jenkins.war
Wait for a couple of minutes till Jenkins is fully loaded. Needs 2GB memory.
Try going to the browser on http://xx.xxx.xxx.xxx:8080/jenkins/ and it will work...
Took me one day to find the solution.
Here is how I resolved this issue:
# service tomcat status
tomcat start/running, process 996
# service tomcat stop
tomcat stop/waiting
# service jenkins status
Jenkins Continuous Integration Server is not running
# service jenkins restart
* Restarting Jenkins Continuous Integration Server jenkins [ OK ]
# service tomcat start
tomcat start/running, process 3839
# service jenkins status
Jenkins Continuous Integration Server is running with the pid 3694
Refresh your browser and Jenkins should be up and running.
Hope this helps!