I have some security certificates setup on multiple domain variants for my website. I have been following this guide on Bitnami:
https://docs.bitnami.com/aws/how-to/generate-install-lets-encrypt-ssl/#step-5-renew-the-lets-encrypt-certificate
I managed to create the certificates, but am now trying to renew them with this command:
sudo lego --email="name#email.com" --domains="mydomain.com" --domains="www.mydomain.com" --domains="mydomain.co.uk" --domains="www.mydomain.co.uk" --domains="mydomain.technology" --domains="www.mydomain.technology" --path="/etc/lego” renew
When I run this it just hangs. I get nothing back. Any ideas?
Related
I am facing a weird issue for an Command line application created from Xcode . I am running a script to fetch expiry date of one of the certificates available in Keychain access in Mac using the below command
security find-certificate -c "CertificateNameHere" -p | openssl x509 -text | grep "Not After"
When I run it locally through Xcode I am able to fetch the date. But when I Run the app as a service from one of the Library folder the expiry date is not fetched. Instead I am getting a error
PEM routines:CRYPTO_internal:no start line:/AppleInternal/BuildRoot/Library/Caches/com.apple.xbs/Sources/libressl/libressl-47.140.1/libressl-2.8/crypto/pem/pem_lib.c:684:Expecting: TRUSTED CERTIFICATE
Though the certificate is trusted
I tried lot of solutions like Trying to find a proper solution to get the expiry date of one the certificates available in keychain but there is no luck. So I am posting it in stackoverflow. I tried another solution to use Mac Xcode security framework to fetch the date using swift but The issue persists.
The probable reason to your trouble is access permissions.
When the script is run as a service it has another user and different/none environment context (Like crontab service).
You can fix this by providing the service with proper login user, and initialize the service with proper source command to respective .profile or .bash_profile script.
I have issue with the cert manager which prevents me from synchronizing the robot with the cloud cluster.
It seems that it is due to a certificate error some way I can solve it.
the logs of cert manager:
1 controller.go:200] cert-manager/controller/orders "msg"="re-queuing item due to error processing" "error"="error creating new order: acme: urn:ietf:params:acme:error:rateLimited: Error creating new order :: too many certificates already issued for exact set of domains: www.endpoints.guminator.cloud.goog: see https://letsencrypt.org/docs/rate-limits/" "key"="default/cloud-robotics-2181866887"
This is hitting the "Duplicate Certificate limit of 5 per week" mentioned at https://letsencrypt.org/docs/rate-limits/. https://tools.letsdebug.net/cert-search?m=domain&q=www.endpoints.guminator.cloud.goog&d=168 shows when the certificates were created.
For a short-term resolution: I'd hope it will start working again in the next days, since the first certificates were issued on the 12th.
For a long-term resolution: Have you done anything that would cause this, for example deleting and recreating the cluster multiple times? If you need to do this regularly, you have two options:
Back up the certificate
https://cert-manager.readthedocs.io/en/release-0.9/tasks/backup-restore-crds.html suggests the following approach for backing up and restoring the configuration:
kubectl get -o yaml \
issuer,clusterissuer,certificates,orders,challenges > cert-manager-backup.yaml
kubectl get -o yaml secret letsencrypt-prod > cert-manager-secret-backup.yaml
Then, to restore after recreating the cluster:
kubectl apply -f cert-manager-secret-backup.yaml
Caveat: I have not tested this approach.
Use the Staging environment
https://letsencrypt.org/docs/staging-environment/ states that the staging environment allows 30,000 duplicate certs per week. You'd need to:
edit src/app_charts/base/cloud/cert-manager-issuers.yaml to refer to https://acme-staging-v02.api.letsencrypt.org/directory
configure the clients to trust the staging CA: https://letsencrypt.org/certs/fakeleintermediatex1.pem
I have a working setup where Let's Encrypt certificates are generated with certbot. I wonder how you effectively test whether the renewal will work in production.
The certificates last for 90 days. Is there a way to reduce the lifespan to, for instance, 10 minutes, to see if the renewal works? (Using the staging system for that is fine.)
If you have an alternative approach how to make sure that your renewal code works (without having to wait for 90 days), it would also be appreciated.
You use the --dry-run option. E.g.:
$ sudo certbot renew --dry-run
From certbot -h:
certbot [SUBCOMMAND] [options] [-d DOMAIN] [-d DOMAIN] ...
...
--dry-run Test "renew" or "certonly" without saving any certificates
to disk
This ensures that the certbot can validate your domain with your current configuration.
If you really want to save the certificates to disk and see if your system is using the new cert, then you can also use the --force-renewal option. In that case, you should visit your website and check that the active certificate is the new one. If it isn't, you likely need to adjust your cronjob to restart your web server. E.g.:
certbot renew && service apache24 restart
You can use "certbot renew --force-renewal"
https://certbot.eff.org/docs/using.html#configuration-file
--force-renewal, --renew-by-default
If a certificate already exists for the requested
domains, renew it now, regardless of whether it is
near expiry. (Often --keep-until-expiring is more
appropriate). Also implies --expand. (default: False)
All of a sudden, with no change to the Xcode build server, I started getting an error, even across different bots, branches, and apps (all are Mac apps). I didn't change any software or configuration on the build server (that I know of), or even sign into it. I get the error once during analysis:
Check dependencies
Code Sign error: Multiple matching codesigning identities found: Multiple codesigning identities (i.e. certificate and private key pairs) matching “Mac Developer: OS X Server (N________L)” were found.
And again during Testing (though my tests pass – the one above is what fails the build):
Testing failed:
Multiple matching codesigning identities found: Multiple codesigning identities (i.e. certificate and private key pairs) matching “Mac Developer: OS X Server (N________L)” were found.
I have tried the following, triggering a build after each step, with no change in the message:
Triggered another build
Updated to the latest Xcode on the build server (6.3.2)
Searched through Keychain Access for any "OS X Server" certificates or keys, finding none
Removed all Developer Teams from Server.app. Note: this acted weird. I had to remove it twice before the setting read "No Teams", but now it's stayed that way
I signed in to add my team again
Removed it again, which still had to be done twice before it "stuck"
Restarted the machine, multiple times
Removed all provisioning profiles from /Library/Developer/XcodeServer/ProvisioningProfiles
Signed in with my developer account again after removing the provisioning profiles. They have been recreated, but the error remains
I turned off "Perform analyze action" in the bot, which did get rid of the message, but turning it back on, or turning on "Perform archive action", reintroduce it, so that's not an option (also, I want static analysis performed, which is why it's turned on in the first place).
Assuming for the moment that Xcode Server's list of signing identities is corrupted, how would I go about resetting them, outside of Server.app (since I already removed the Development Team there)? I found a couple of directories that seem like candidates for some troubleshooting and/or backup restoration, but I'm hesitant to mess around without knowing for sure what they're for.
/Library/Developer/XcodeServer/Certificates
/Library/Developer/XcodeServer/Keychains
I noticed that my provisioning profiles all expire on May 20, 2016. This means my old ones expired two days ago (5/20/2015), which was between my last successful (5/19) and first failed (5/21) builds.
So now, knowing the source of these failures, the problem now becomes: how do I clear out the old provisioning profiles (or certificates, etc.) that are causing the duplicates?
The server is up-to-date on Yosemite (10.10.3), Server (4.1), and Xcode (6.3.2).
Update
I'm trying to list codesigning identities, but can't get even a single "Mac Developer: OS X Server" to show up, let alone multiples. These are the commands I've tried, which only list the non-Server identities in the keychain:
security find-identity -p codesigning
sudo -u _xcsbuildd security find-identity -p codesigning
sudo -u _xcsd security find-identity -p codesigning
It looks like a bug in Server did in fact introduce a duplicate signing identity. I reported it as rdar://21080937, if you'd like to dupe it.
In order to fix it, I had to learn about how Xcode Server stores signing identities (thanks entirely to an extremely helpful answer to an unrelated question).
Xcode Server stores Developer Program certificates in
/Library/Developer/XcodeServer/Keychains/Portal.keychain
Following the steps below, I was able to open the keychain, find the duplicate, remove it, and put it back. These steps are adapted from the answer linked above.
Sign out of the Developer Portal from Server.app by removing the developer team you're having issues with
Copy the Portal keychain to your desktop:
> sudo cp /Library/Developer/XcodeServer/Keychains/Portal.keychain ~/Desktop/
Password: your-administrator-password
> sudo chown `whoami`:staff ~/Desktop/Portal.keychain
Set the Portal keychain password to “123”
> security set-keychain-password -o "`sudo cat /Library/Developer/XcodeServer/SharedSecrets/PortalKeychainSharedSecret`" ~/Desktop/Portal.keychain
New Password: 123
Retype New Password: 123
Open the Keychain in Keychain Access:
> open -b com.apple.keychainaccess ~/Desktop/Portal.keychain
Unlock the “Portal” keychain using password “123”
Find the duplicate keys with the name listed in the error
Remove one (I picked the one modified less recently, but it may not matter)
Lock the “Portal” keychain, quit “Keychain Access”
Reset the Portal keychain password:
> security set-keychain-password -p "`sudo cat /Library/Developer/XcodeServer/SharedSecrets/PortalKeychainSharedSecret`" ~/Desktop/Portal.keychain
Password: your-administrator-password (optional step)
Old Password: 123
It may or may not ask you for your administrator password again, pay attention to the prompt.
Backup the original keychain
> sudo cp /Library/Developer/XcodeServer/Keychains/Portal.keychain /Library/Developer/XcodeServer/Keychains/Portal.keychain.old
Copy the Portal keychain back
> sudo cp ~/Desktop/Portal.keychain /Library/Developer/XcodeServer/Keychains/
Fix the new keychain's permissions
> sudo chown _xcsbuildd:_xcs /Library/Developer/XcodeServer/Keychains/Portal.keychain
Since the system caches open keychains, restart the server
Add your developer team back, in Server.app
Run a build, verifying everything looks good. If so, remove the backup copies of the keychain
> rm ~/Desktop/Portal.keychain
> sudo rm /Library/Developer/XcodeServer/Keychains/Portal.keychain.old
I use sourcerepo.com as SVN server. My XCode5 bot complains : error validating server certificate for "https://myproject.sourcerepo.com:443"
- the certificate is not issued by a trusted authority. Use the fingerprint etc....
How can I make my XCode Server accept this svn server and retrieve sources ?
thanks for your advice
Frank
Verify why the certificate is untrusted. (E.g., is it a self-signed certificate?)
Start Terminal and run svn info https://myproject.sourcerepo.com:443/<path-to-repository>. Accept the certificate permanently when prompted.
I found a way to make it work from the Xcode 5 release notes:
https://developer.apple.com/library/ios/releasenotes/developertools/rn-xcode/xc5_release_notes/xc5_release_notes.html
Communicating with a remote SVN repository over HTTPS can fail with an
error similar to “Error validating server certificate for server
name.” Edit the file
/Library/Server/Xcode/Config/xcsbuildd.plist
and change the TrustSelfSignedSSLCertificates key from false to true.
Then, from a Terminal window, run:
sudo killall xcsbuildd
I did exactly the above. To edit the file you actually need to
sudo vi /Library/Server/Xcode/Config/xcsbuildd.plist
After restarting the build daemon I was able to get my Xcode bot to checkout the sources from the remote repository and perform the integration. Hope this helps!