Hot answers tagged certificate
Import/Export works differently in Xcode 5/6. This Apple Developer guide shows you how to do it. Your account is shown under Xcode → Preferences → Accounts, and can be exported by clicking the gear icon () in the lower-left.
The reason: After installing Security Update 2015-004, multiple users found that they couldn't browse to any website using the root certificate "VeriSign Class 3 Public Primary Certification Authority - G5" without a security warning ("invalid certificate"). 2015-004 updated the list of trusted root CAs, and for a reason I'm still unclear about, many of us ...
You can do this from within Xcode. From the Organiser, on the devices tab, you can export your developer profile to a file which you can then import into Xcode on another computer. The step by step process is explained in ...
Apple KB article HT3930 explains how to configure SSL for servermgrd, the Server Admin web interface. It applies to Mac OS X Server 10.6 so until Apple updates this article part of the steps are confusing / obsolete. Luckily, on Mountain Lion Server (10.8) servermgrd's certificate is stored in the same location as on Mac OS X Server Snow Leopard: in the ...
There is no way to add Certificate Authorities to Chrome.app on iOS. The only way to manage them is in Settings > General > Profiles. It seems like this is an issue with Chrome.app that's not resolved yet. See Chrome for iOS ignores trusted root CA certificate. You may get additional help by posting to the Google Chrome Forum (linked before).
Firstly you'll need to obtain the SSL certificate, sending it to you via email or grabbing it from a web. Once opened (tapping on it from the email attachment, for instance) an installation process will start. On the Install Profile screen, tap on Install. A warning message saying that Installing this profile will change settings on your iPhone will ...
The answer, as discovered by shizmob, is that Apple moved the location of this preference in Maverics to /Library/Preferences/com.apple.security. So what you need to run is sudo defaults write /Library/Preferences/com.apple.security RSAMaxKeySize -int 8192
A report on forums.macrumors.com seems to be fairly similar to yours. This happens as well in Safari 5.1 and is very recent. The solution was to delete: ~/Library/Preferences/com.apple.security.plist
Check that the date is correct. This is an error that can be received if your date is set utterly incorrectly, typically due to a flat battery prior to install and not being able to connect to an NTP server to correct.
I've since solved the problem, though I'm not sure if this is the right answer for everyone. The problem seemed to come from the certificate automatically generated from apple (com.apple.idms.appleid.prd.[large character string]). A quick Google search didn't tell me what this certificate was for, but I'm sure that deleting it was probably not the best ...
Yes the installed certificates are valid, however I would advise updating to the latest version of Leopard and make sure that the compromised Diginotar certificates are uninstalled: This link at ps Enable provides an easy method for this. On Root Certificates, they are by their nature long lived since they are the "Master" certificates and having them ...
If You want to change set of system root certificates, they are in /System/Library/Keychains/. Example of using security there is in this answer to similar question.
Apple's .mobileconfig files are signed using PKCS7. The signing certificate data can be shown using the following command: openssl pkcs7 -inform DER -print_certs -in ~/Settings.mobileconfig You can copy/paste ASCII certificate data from the output into a plain text file (with a .cer filename extension) to create copies of the certificates: -----BEGIN ...
Unfortunately, Keychain Access (Certificate Assistant) does not have the ability to include a CRL Distribution Point inside of a certificate's extensions section in certificates that it generates. You'll likely notice that your current CA does not have a CRL distribution point specified (even if you've enabled CRL signing as an allowed usage of that ...
Restore the contents of these three directories from a recent backup: ~/Library/Keychains /Library/Keychains /System/Library/Keychains On my system this comprises 18 files and a subdirectory in the user folder ~/Library/Keychains
I finally solved the issue by opening the web sites that misbehaved, one at a time, in Safari. From there you proceed to trust each and every certificate. They are then re-added to your keychain. More can be found in this KB. I'd like to thank @bmike for doing his best to assist. Restoring from backup would probably work (if I had one - silly me).
A friend (who was too lazy to write the answer here) hinted me that the root certificates in Mac OSX are stored in the keychain and suggested two different ways around the problem. In order to make openssl library (used by svn) to locate them, you need to manually export them and store them in /System/Library/OpenSSL/cert.pm. The process is described ...
Provisioning Profiles can be shared without problems between developers. For them to be valid and usable, though, having both Public and Private keys is needed. The Public key is stored in the Certificate whilst the Private has to be exported from the certificate's creator Keychain App.
It took me a minute to find what he was talking about but near the right corner of the message toolbar you will see an icon that looks like a burst with a checkmark. Click this and it will turn to a burst with an x. Here is a screen shot.
You need to export your private key from Key Chain access of Mac OSX in which certificates are running successfully or from which developer certificate made and download certificates from Apple Developer Portal, it will work as it works for me.
You need to import the cert via Server.app; that'll add it to the System keychain and several other locations that allow non-keychain-aware services to use it. I'm not sure why it'd be hanging, but I can think of a few things to try: If it's not a self-signed certificate, you probably need to import the appropriate intermediate certificate(s) by dragging ...
I think this Apple support article has the list you're looking for. It is updated as changes are made: iOS: List of available trusted root certificates And StartCom is on there.
You can script keychain events from the command line with the security command. On Lion and earlier, the worst that will happen if you delete all the system roots is you won't be able to run software update or use iTunes and other applications that interface with secure web services. It might be easier just to make a keychain file you like and shove that in ...
Currently this is how the Apple Configurator works - it doesn't have a provision to load a certificate but instead generates self-signed ones automatically. If I run across a way to hack this, I'll link it here, but if you need profiles to arrive with a signed certificate look into Lion server or another MDM solution. In practice - you only see the ...
Were able to solve the issue myself. For some reason, there were a few root certificates in my login Keychain, which have been revoked and replaced with newer certs in the System Roots keychain. Deleted those certs from my login keychain and everything works fine again.
It looks like the Mavericks installer is making a verification of an authenticated checksum with a certificate. If your date is out of scope of this certificate window of validity this process fail. Look at: Jonathan Mohar receipe to fix a sadistic error message. A more usefull error message might have been: The certificate of your Mavericks installer ...
The actually "certificate" itself is not encrypted. Your private key, which is used with the certificate, is usually encrypted. It is encrypted with the passphrase you chose when you created the private key. You might have done that a while earlier than creating this specific certificate, if you have multiple certificates - so be sure to try "old passwords" ...
Literally right after typing this question up, my coworker found the solution. Apparently, the "JAVA_HOME" variable changes based on the context of where you ran your jar. If you run the application directly, the variable leads to /Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home Whereas running it from bash/terminal/eclipse causes it to ...
It looks like you might not have actually "trusted" it, but rather made "exception" for it as detailed here: https://blog.httpwatch.com/2013/12/12/five-tips-for-using-self-signed-ssl-certificates-with-ios/ If you did import the certificate, then the above website shows how to remove the "profile" that contains the certificate. To remove the exception, it ...
Should I worry about this? You should always distrust SSL connections that are using expired certificates. This could indicate a simple oversight on the part of the website operator or it could indicate a malicious attempt to intercept encrypted communications between the website and your browser. Heed your browser's warnings and don't load the page ...
Only top voted, non community-wiki answers of a minimum length are eligible