I am using Go with self-hosted Git (gitea) with self-signed certificate.
However with self-signed certificate most Go commands don't work correctly including "go mod". I have to do "go get -insecure ...." before I do any other go mod commands. I can't even do "go list" because it doesn't seem to accept the -insecure flag. And most IDE tool won't work correctly, especially GoLand.
What is the best way to go about this kind of issue? Do I have to get the certificate and add to trusted certificate locally? Or is there another way to go about this?
As #Vorsprung said, I as our MIS to provide the self-signed CA and installed and trust it on my local computer.
Related
I want to compile curl in a such a way that it can access the macOS keychain for certificate lookup. I have added an internal company CA certificate to my system keychain and am trusting it.
When I build curl as described in the docs with Secure Transport I am able to connect to a server with a certificate signed by our internal CA. However, this does not work as root.
./curl company.com # works
sudo ./curl company.com # invalid certificate chain
When I repeat the same tests with the curl version that ships with the os, it works in both cases. Same results with a small example program when I link against my build vs linking against Apple's curl.
I've also tried to compile it with libressl (with and without Secure Transport) but then keychain access doesn't even work as normal user.
Any idea what's going wrong? How does Apple compile curl so that it works as root?
You can fetch the source files of Apple's curl from here curl-121.100.3 and see, how they compile curl, compare them with the vendor's files of the release 7.64.1.
I am getting errSecInternalComponent when running the codesign command.
If I go to the keychain and change the certificate to always trust and run codesign command again, I get Warning: unable to build chain to self-signed root for signer "Developer ID Application: xxxxxx (xxxxxx)"./workspace/Myapp.app: errSecInternalComponent
This first time this happened was when I exported the developer certificate from another MacOS and imported it. Then I tried deleting the keychains, recreating it, installing apple root certificates, but still getting the same error.
Finally, I generated a new developer certificate and added it to the keychain, but still not working.
I am not sure what's different about this MAC. It's running Majave now. When the problem first happened it was running High sierra.
There could be many possible reasons for this error. Two frequent issues are:
codesign tool does not have access to the keychain item. Either explicitly give access to codesign or allow all applications to access it.
Unlock the keychain: security unlock-keychain <Full path to keychain>
Can get the full path using, security list-keychains
There were two problems:
I had duplicate identities in my keychain, which is the same with this
Duplicate identity after importing single certificate in OSX 10.10.3
The access permissions for the private key needs to allow codesign or allow all.
Not exactly the same issue, but we encountered a errSecInternalComponent during a build on jenkins. Increasing the timeout after which the keychain is closed again fixed it.
I am building a Windows script for which I'm using the Windows version of wget. The page I need to query is protected and requires a certificate to access. I currently have that client certificate installed on the computer. How can I use this certificate with wget in order to access the protected web page? Export it somehow from the Windows certificate manager?
Thanks!
I'm not sure of the syntax for using a certificate with wget, but you probably need it in PEM format:
How to convert .crt to .pem
My installer is created using PackageMaker. After that I codesigned the installer using the following command.
productsign --sign 'Blah, Inc.' Install.mpkg/ CS/Install.mpkg
This seem to work pretty well and I could see that it is signed using the following command.
pkgutil --check-signature Install.mpkg
Since the certificate is installed on my system in keychain, the installer seem to show a little lock on top right corner. Clicking this opens up the certificate.
If the installer is placed in a system without the certificate installed the lock is no longer seen. However I could still run the command to check for certificate.
1) Is there a graphical way to check for code signing before installing? (I do not want to run command line)
2) I removed a folder from the mpkg file using finder to see if the installer will complain of tampering. But that does not happen. Is there a way the installer can stop install if it is tampered?
3) I also code signed all the binaries in my package (mostly daemons) using xcode's option to use certificate. Again I am able to see the binary as signed, however I do get a message
kernel[0]: CODE SIGNING: cs_invalid_page(0x1000): p=224[MyDaemon] clearing CS_VALID.
Googling, I found http://feedback.photoshop.com/photoshop_family/topics/photoshop_13_0_4_x64_how_can_i_get_rid_of_the_could_not_complete_your_request_because_of_a . However I am still not very clear what they are getting at. Could someone help me?
You can sign .mpkg packages but you must sign it with the Developer ID Application cert and not the Developer ID Installer cert.
When you sign the .mpkg you get a number a warnings that the inner packages must be signed but the signing seems to be valid with or without the inner .pkg signed.
I have tested that modifying an internal .pkg causes the .mpkg to fail the Gatekeeper check
So for the each internal .pkg files you should:
sudo productsign --sign "<Developer ID Installer: Cert>" "<source.mpkg>/Contents/Packages/<source.pkg>" "<destination.mpkg>/Contents/Packages/<source.pkg>"
for then for the .mpkg do:
sudo productsign --sign "<Developer ID Application: Cert>" "<Source .mpkg>" "<Destination .mpkg>"
You can sign only flat packages. Your package has extension .mpkg which I believe is the older bundle format. Make sure you are using flat packages if you want to sign them.
I just got a new Mac (with Lion) and am setting everything up, but I am stuck on this SVN certificate trust error for my repositories on Assembla.
The most common solution seems to be to move to Terminal and perform some svn operation on my working copy there, then respond to permanently trust the certificate when prompted.
Here is where I am stuck. With the Terminal, I never get a certificate trust prompt! I can happily list, commit, check out a new copy, anything, no problem. With svnX, again, no problem . Neither way am I ever prompted to trust the certificate.
But, with XCode 4.2 or Coda, I get stuck on the certificate trust error. I've tried removing anything in the keychain related to svn or assembla, doesn't help. I've tried browing to my repository in Safari, and again I can log in and am never given a certificate prompt.
I am utterly baffled. If anyone has any ideas, please help! Thanks!
Coda gives me this:
svn: OPTIONS of 'https://subversion.assembla.com/svn/my/repo/path': Server certificate verification failed: issuer is not trusted (https://subversion.assembla.com)
And XCode gives me this:
Error validating server certificate for 'https://subversion.assembla.com:443':
- The certificate is not issued by a trusted authority. Use the
fingerprint to validate the certificate manually!
Certificate information:
- Hostname: *.assembla.com
- Valid: from Thu, 24 Mar 2011 19:30:40 GMT until Sun, 24 Mar 2013 19:30:40 GMT
- Issuer: 07969287, http://certificates.godaddy.com/repository, GoDaddy.com, Inc., Scottsdale, Arizona, US
- Fingerprint: ae:b0:b6:94:14:5f:4b:28:d2:82:68:ae:e9:18:85:b3:ea:36:ee:f2
(R)eject, accept (t)emporarily or accept (p)ermanently?
svn: OPTIONS of 'https://myuserid#subversion.assembla.com/svn/my/repo/path': Server
certificate verification failed: issuer is not trusted (https://subversion.assembla.com)
You need to make sure you use the svn binary in the Developer Tools package. If you go to the directory under version control and type
/Developer/usr/bin/svn up
You should be prompted to accept the cert, press p to accept permanently and then xcode should work.
On newer versions of XCode 4 which come as an appbundle, try this instead:
/Applications/Xcode.app/Contents/Developer/usr/bin/svn up
If the Xcode appbundle is elsewhere, just edit the path accordingly.
Ok, I finally stumbled into a fix, out of desperation as I as exploring moving to Git and moving to Bitbucket from Assembla.
I installed MacPorts and did the git-svn install (sudo port install git-core +svn). Once it was done (installing a lot more files than I expected, and taking a lot longer), I tried an initial clone of my svn repository into Git (as in: git svn clone myrepourl -T trunk -b branches -t tags).
At long last, I was faced with the beautiful prompt asking me to accept Assembla's certificate, and one "p" later, Coda and XCode are now happily connected to subversion again. Now I can move to Git at my leisure instead of in a panic.